Resources > Articles

Getting Back to the Roots of Agile

Author
  • Scott Williams

    Scott Williams is director of software development at Tallwave where he oversees the development team and works with clients to gather requirements, map timelines, manage development and complete products. He has worked with notable brands, including American Express, Equality Health and Weave Education. Prior to Tallwave, Scott served as a software development consultant to multiple Fortune 500 companies. Connect with him on LinkedIn.

rootsagile_20170719163345_0

Want to hear a joke? What do you call a process that has multiple complex steps, requires detailed explanation and dogmatic adherence to rigid tenets defined by expensive consultants? Agile. Or at least, that’s the way it feels in 2017. If you aren’t using story points, spending hours building a backlog, reviewing burndown charts and using appropriate terminology, you’re “doing it wrong.”

 The entire thing makes me feel exhausted and locked into a process that doesn’t feel very agile. The authors of the original Agile Manifesto never intended for it to feel so restrictive. In fact, not too long ago one of those authors revisited the whole thing. He suggested a return to the basics and a simple workflow that involved just four steps.

  • Find out where you are
  • Take a small step towards your goal
  • Adjust your understanding based on what you learned
  • Repeat

 And “When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.” As the expression goes, everything else is just details.

A Disciplined Approach to Iteration

This doesn’t mean working with agility is without discipline—quite the opposite. You need to be extra dedicated when you examine your past progress in order to improve. It also requires that everyone on the team be willing to admit when they are wrong, which is a tough sell.

Discipline is especially important to have as you add more projects, as it can be easy to fall back into a particular system or methodology as work intensifies. However, while systems can be good, they are by their very nature generalized. The same one may not work for every project.

Let’s use meeting cadence as an example. When we start a project, we tend to have standup meetings every day. This is a standard standup meeting: Each team member tells the team what they worked on, what they plan to work on and if they have any blocks.

However, as our team members become more comfortable with each other, these discussions begin to happen in chat or in person during the day. It became apparent that the standups were becoming a rehash of what was already happening. We realized this and cut the meetings back to three times a week, then two. The nature of the meetings also changed as they became more about overcoming blocking issues and handling potential blockers.

In this scenario, continuing to follow standard scrum principles would have meant an unnecessary interruption in the team’s day, and everyone would have been bored. But reviewing our processes with an agile mindset made the decision to change easy. Best of all, if the change to the meeting had been wrong, we could have easily reverted to our daily standups. That’s the benefit of having an agile mindset vs. adhering to an agile process.

Now, we don’t do a formal review of our processes; there just isn’t enough time for that. We do, however, give our team the autonomy to question processes. And it was this that enabled us to realize we were repeating ourselves when a team member brought it into question. And that’s a key part of an agile mindset: empowering your team to make this kind of recommendation, and then listening to them and acting on it.

Building on the agile cornerstone allows you to iterate in other areas too, not just meeting schedules. Is your estimation constantly failing? Change it. Try to improve it, just a little bit, and go from there.

Remember, if you try to throw a complex version of an agile methodology at a team, it will take longer to implement than it would to start simple and iterate. As John Gall said, “A complex system that works is invariably found to have evolved from a simple system that worked.” 

Gaining Team Buy-In

Getting team buy-in to this change in mindset can be difficult at first. People tend to like systems, even if they’re cumbersome. Overcoming the “that’s the way we’ve always done it” hurdle can be challenging. It requires management to understand their team and how each person works. That kind of trust can take time to earn.

Since developers tend to view things through a coding lens, consider explaining your processes in their terms: We refactored our meeting process and reaped benefits similar to the benefits you reaped from refactoring a codebase. If a developer doesn’t get excited about the prospect of refactoring the entire process, then you might have a different problem on your hands. That kind of iteration benefits the team and the project.

In larger organizations, it also can be difficult to get executives and clients to agree to work more loosely than they are accustomed to. And when the pressure is on, chances are they will try to revert to what they are most comfortable doing, which often involves poor collaboration and a “just-get-it-done” mentality. This can lead to burnout. It is up to you as the service provider to guide them on the proper path.

Fortunately, if you are improving, your productivity will increase. If future change is easier, it will be faster. When clients see that outcome, they will trust you more. It then becomes a virtuous circle, but must still be continued. 

When The Agile Manifesto was written, it was a shot across the bows of all kinds of software projects. However, it was written to describe systems, not to prescribe a single system for all cases. If you fall into that pattern, you won’t reach your peak performance.

Author
  • Scott Williams

    Scott Williams is director of software development at Tallwave where he oversees the development team and works with clients to gather requirements, map timelines, manage development and complete products. He has worked with notable brands, including American Express, Equality Health and Weave Education. Prior to Tallwave, Scott served as a software development consultant to multiple Fortune 500 companies. Connect with him on LinkedIn.

Author:

Other Resources in this Series

Most Recent

Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd
Article

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...
Creating a product roadmap: what should you include
Article

A Guide to Product Roadmaps: How to Build One That Works

A product roadmap is a frequent request from the sales force and others in the company. ‘What’s coming in the next release and the ones after that?’ Long buying cycles common with strategic products often...
Dry erase board with product roadmap drawn on it
Article

How to Build a Brilliant Visual Product Roadmap

Building roadmaps is a crucial part of a product manager’s job. Yet most product managers still use outdated tools for roadmapping—Excel, PowerPoint, wikis, etc. The good news is that there’s a better way. Executives have...
Product Datasheet
Article

How to Write a Kick-Butt Product Datasheet

If your datasheet passes the all-important skimming test, it's more likely that buyers will read it in detail. Here are 10 tips to help you write a datasheet that buyers actually read.

OTHER ArticleS

Article

Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd
Article

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Subscribe

Subscribe