I talk to a lot of developers, and I read a lot about teams and teamwork on the Internet. I absorb a lot of information about “projects” and I have to say that there’s a lot of people out there who are deceiving themselves:
“We are an Agile/Scrum shop; we have daily stand-ups, two week sprints, with sprint retrospectives, incident postmortems, and we release every six months.”
No you’re not. You’re lying to yourself. You’ve latched on to a fad, and like cargo cults in the post-WW2 Pacific theater, you’re using the right vocabulary, saying the words, performing the ceremonies, and going through the motions. The problem is that your executive team despite buying in to this “Agile Transformation” you sold them is starting to get antsy that the results aren’t what was promised. Sure, you’re moving faster, but your defect rate is still too high, and you’re still delivering features that fail to fully capture the intended business value.
The fad isn’t Agile. The fad is what I like to call Fauxgile.
The Problem
The saddest part, is that while teams usually do see improvements from dabbling around the edges of Agile, there’s way more below the surface. Somehow, they cannot shake the vestiges of “THE Plan”. It’s still there, in all of its ugliness, just sliced and diced into two-week mini plans. Because they haven’t truly addressed the constraint of the system, they’re going to slip, and they can never catch up. They’re lulled into complacency, it’s easier to go along than fight it. They let inertia become the system’s new constraint; they fall back into old habits, pushing features, and slaving away in subservient conformance to “THE Plan”.
They dress up their old waterfall SDLC in some new clothes, replacing a few meetings there, adding a few other meetings over here, and for a time, things get better. But I’m here to tell you that the Emperor is STILL naked!
It’s OK to admit that you have not fully embraced Agile principles. But for organizations that want to improve, I believe that there are four main areas in which Fauxgile organizations fall short: User Engagement, Engineering, Managing Effort, and Corporate Leadership.
User Engagement
How often is the team working in direct contact with actual users of the application? What is the cadence of deliveries? Do users have to wait months, quarters, or years to harvest value from the application? How is user feedback connected to ongoing effort? How do users learn when their feedback has been received and acted upon by the team? Is the team observing users directly? Do they asked pointed questions to drill down and bring to the surface latent value?
Fauxgile organizations tend to suffer from critically low User Engagement. This is sad because you cannot have read the Agile Manifesto and its backing principles without tripping over the following:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
http://agilemanifesto.org/principles.html
Literally the first principle is about User Engagement. And it’s only by engaging directly with the end users who will use the application to create business value that the application team knows what to build. Tight feedback loops where the application team works side by side with the business, incrementally delivering features requested by real users.
Engineering
How do you connect contributors to avoid siloism, and ensure that the application benefits from the expertise of the entire team? Is excellence, and in particular good architecture and design, a priority? Does the team weigh speed of delivery against ongoing costs, using technical debt effectively? How is the application tested, does the team still rely on manual testing? Do you still have a buildmaster, or are you using CI and CD tools? Have you ruthlessly questioned and attacked manual processes, eliminating costly and error-prone tasks by leveraging automation and process improvement? Have you adopted “______ as Code”?
Fauxgile teams fall into the chaos that has been unfortunately conflated with Agile. To achieve agility requires doing the small things right, each and every time. That is only possible by rigorous engineering: Identify the task that is the biggest source of error or inefficiency. Make every improvement possible to automate or optimize the task in question. Adjust adjacent tasks to improve flow, offloading effort to other resources if possible. Re-analyze the set of tasks, and apply the steps recursively on the task that is the new biggest source of error or inefficiency.
Automation is the future of software development. Gone are the days where development teams throw “Feature Complete” applications over the wall to QA and Operations to test and run in production. Everyone on the application team from developers to test engineers to server administrators needs to know how to code. Applications are code. Servers are provisioned and configured with code. Code is written to test other code. Applications are installed onto servers with code.
Managing Effort
Is the application’s feature set and capabilities malleable, reacting to changes in business environment? Is the team free to experiment, changing, or even abandoning, processes and procedures? How frequently do you carry out retrospectives and postmortems? When and what was the last big revelation from a retrospective? What did the team learn from that discussion? Did that new knowledge spawn experimentation, feeding back into and strengthening the team?
Caught up in the ceremony, Fauxgile organizations kicked project managers to the curb, installed Project Owners, and hired Scrum Masters. They still hold meetings where they solicit mountains of requirements. Projects turn into giant wishing wells where every manager’s special pet pony initiative gets a spot in the parade. They cannot see the forest because all of those damn trees are in the way.
Agility is about building something quickly that is “good enough” and iterating on enhancements, capturing changes to enhance competitive advantage. Agile teams are faithful to a collaborative cycle of learning and improvement. The future of project managers lies in servant leadership, helping the team to overcome obstacles, and shine a light on blind spots.
Corporate Leadership
How does the application affect the organization’s long-term strategy? Have you shared that vision to drive team members to more deeply engage with the mission? What are you doing to ensure that what is being delivered drives real business value rather than “checking the boxes” on some requirements to-do list? What is the primary performance indicator for the application team? How does changes in that indicator affect prioritization? Can that indicator be used to predict or detect problems within the team? Have you empowered the team to self-organize and make adjustments to its behavior to reinforce positive feedback loops?
Leaders in Fauxgile organizations still treat IT, and especially software development, like a captive consultancy. They “negotiate” estimates as if they were prices quoted in fixed-bid contracts. They are skeptical about these new hyped-up project management philosophies, but have caved because their IT peers have convinced them the only way they’ll be able to recruit developers.
In Agile organizations leaders are concerned with cultivating the fire that burns inside their employees; those employees were hired because they had that passion for the mission of the organization. Agile Leaders understand that their vantage point outside “the trenches” make them poor candidates for knowing what features and capabilities will yield the best outcomes. Application teams are empowered to work directly with their users to ensure that users get tools that will really improve their daily work.
There is one metric, one indicator, that matters: did the team deliver an incremental enhancement to the application that will result in increased capture of business value going forward?
Demonstrating progress and success is as simple as answering a yes/no question. Even as a lagging indicator, past performance is a great predictor of future success; keep cycle times short and re-prioritize as necessary. Put the team in the driver’s seat, and set the expectation that they should not only win, but learn how to win bigger and better in the future.
The Conclusion
Can you be successful in a Fauxgile? Sure, I guess… But once you’ve experienced what Agile can be like, Fauxgile will leave you disappointed, always thirsty for more.
What are your experiences with Fauxgile? Did your organization ever complete its transformation? What were the hardest steps on the journey? Please share in the comments section below.
In Starke Contrast 
One Reply to “”
Comments are closed.