Stop letting your large enterprise ship bad software.
What does it mean for a large enterprise to apply Agile and DevOps practices to make itself more competitive? How do you coach or lead a fundamental cultural transition to being more responsive to user and market demands?
I’ve been a software developer for more than 15 years and have gotten to see how a large enterprise adopts and champions new development practices through a few generations of methodology.
In that time, I’ve seen some things that work and some things that fail. Here’s a few things that I’ve seen that fail.
Agile Anti-pattern: THE Build Guy/Gal. Often when a team begins applying a new practice, a champion must take the reigns to lead the team. But far too often, I’ve seen the natural leaders on a team bring in a technology that doesn’t really get socialized with other team members — they didn’t configure the tool, so they don’t feel ownership.
Best Practice: Continuous Integration & Delivery should be part of the culture not isolated tribal knowledge. Everyone owns the CI/CD process — from test coverage to the build/deploy/test cycle.
Agile Anti-pattern: Feature Bullets. I’ve seen it over and over. I still fight with the practice on a daily basis. You’re in the zone, you’re planning your next release. It’s going to ROCK! But, instead of focusing on the outcomes that a user will value as part of working with your software, a bulleted list of bland generic statements is codified in a slide deck — and THIS! will be your roadmap. Meh.
Best Practice: Focus on the user outcome is essential to effective software delivery, and use cases help everyone understand the goal and the path to achieve that goal outcome. Creating personas which are informed from real user interviews is critical to do this right — the personas become your weighting function for any new use cases that you enable with your software.
Understanding personas won’t give you a specific list of features as much as it will give you a way to begin to “think” like your user; what will they want and value from what we’re delivering? By developing empathy for your users and enabling outcomes, you have the chance to create a more meaningful, personal experience for each type of user. This should also be underpinned by iterative planning, development, and feedback — favor working code over slides. It’s one of the cornerstones of the Agile manifesto and the iterative feedback loop is part of every perspective today — from Lean Startup to DevOps.
A related principle here is that by empowering your teams to deliver based on user feedback, it often means that more senior leaders play a different role than they once might have played. Often, they’re not dictating direction based on their own bias and mental model of the world — but instead, letting the data and metrics lead the team to the “right” answer.
Agile Anti-Pattern: 60 minute daily scrums. By far, this is my most hated anti-pattern. Traditional enterprise culture has revolved for so many decades around the “status” meeting. Too often, “scrums” led by more traditional minded managers or executives devolve into a status update; not a scrum update. Status updates tend involve a bit of “bragging” about all the things you accomplished or all the meetings that you attended. That’s not what scrums are meant to be about.
Best Practice: Daily scrums are valuable forums to identify blocking issues or ensure all team members are aware of critical decisions about use cases or architecture. Scrums are a communication pathway for the team, not the leadership.
And by all means, institute a 60 second time limit for each member’s scrum update.
Agile Anti-Pattern: Emotional decisions about code.
Developers can fall into the trap of valuing the code over the user outcome. As users provide feedback or the risk landscape changes, pivots are required.
“Early in my career as an engineer, I’d learned that all decisions were objective until the first line of code was written. After that, all decisions were emotional.”
– Ben Horowitz, The Hard Thing About Hard Things
When you have to pivot (the use case or architecture), don’t get hung up on thoughts like “I spent so much time writing this, we have to include it!”
Best Practice: No Code Is Sacred (NCIS). This is one of my favorite mantras. I’m constantly reminding myself and my team that the effort that you spent on a feature or clever technical solution isn’t the end goal or what’s valuable. All code that we write is only valuable insomuch as it is the best solution for the user right now. And the needs of our users are constantly changing.
What you can do to make it better.
It’s not all bad though — as a large organization, I’ve found there’s three key aspects about how you deliver software that can make you successful.
Being Agile: How you work.
Ship your organization — focus on multi-disciplinary teams and craft your organization to reflect the architecture you want. Your architecture will often reflect the communication pathways of your organization — and old principle known as Conway’s Law. But you can exploit this for your own goals! If you focus effort on good organizational structure that reflects the architecture and experience that you want, it will often emerge organically.
Physical space is the echo chamber of your mental space. Design physical spaces which foster collaboration; not isolation. I’ve seen this play out as a team used to cubes adapted to an open workspace format. It led to more ad-hoc interactions and fewer scheduled meetings.
Be upfront and vocal about your organization values — and trust should be key. As you focus on empowering teams and pivoting based on user feedback, it requires tremendous trust in your leaders and team members. It means being willing to let them experiment, and sometimes fail if it will generate good learning.
Being Agile: How you ship.
Automation for everything! Build, Test, Deploy, Learn — without automation, you can’t hope to deliver and operate at scale in the Digital Era.
Establish your anchor points in your Continuous Delivery toolchain. Ensure consistency where required; offer choice where possible. Anchor points are places that as an organization, you choose to control across all teams. I’d suggest source control and release automation are the most critical, but it’s up to you to decide. In other areas such as testing, you may let leans choose whatever test framework makes them most effective.
It takes a village. Everyone on the team should feel responsible for the automation that enables delivery. This is a counterpoint to the first anti-pattern above.
Being Agile: How you measure.
Metrics should be a key part of your decision making process. Reviewing your key metrics on a regular basis should be a part of your culture.
Apply Experiment Driven practices to your development so you can learn what works. Don’t be afraid to experiment — define working hypotheses, implement and deliver them, then measure the results and adjust as needed. Being more focused on hypotheses driven development means you form questions, quickly implement a means to gather data and try the alternatives, and you look for real user behavior and feedback to make a final decision. It means you’ll absolutely throw code away for each experiment, but it should also mean a full order of magnitude less HiPPO-based arguments about what the “best” approach is.
Final thoughts.
We owe it to the users of our large enterprises to be relentless in our efforts to transform. In the end, large human organizations always trend towards the behaviors that have sustained them. As you’re advocating for your organization to change, always be on the lookout for the small adjustments the organization will make to new practices to make them look like the old.
