How We Get Agile Transformations Wrong By Trying to Do It All So Right
Sorry to say it guys, but Agile has gone limp over the last few years. As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce. Not great stand-ups.
Technical practices matter. In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that. From a Lean perspective, process adds no customer facing value. But getting rid of all process is crazy talk. Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process. In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company. He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.
But perhaps we don’t have the absolute best talent out there. Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?) Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”? With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?
I’d like to convince you that what’s going to work for your organization and your employees is something in the middle. I, of course, lean into the “better technical practices will yield better outcomes” frame of mind. You may as well. But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire! And the same is true of your organization. It can logically be true that all organizations’ developers are all above average. But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code.
This session will speak to the specifics of the whats and whys.
Outline/Structure of the Talk
- The Problem
- Agile has become an industrialized process today
- Agile has done limp by not emphasizing programming acumen
- Agile instead has gone after primarily Lean wastes, but the industrialized scaled Agile processes have brought that back
- Things That Go Wrong While We Try to be So Right
- We are still mesmerized by good specifications, but now done in Agile “Process Tools”
- We are still cursed with knowledge that we can’t translate into specifications
- We hire based on developer specifications and certifications, and end up with poor staffing
- We can’t stop trying to scale Agile, instead of changing the way our organizations are structured
- We still strive for efficiency, and forgo the organizational effectiveness we actually require
- How We Should Go About Software Development in an IT Setting
- Start by making executable specifications
- Start doing code reviews, and make them realtime
- Start using Coding Auditions when hiring and treat your applicant like an undiscovered film star
- Replace artificial team branding with actual enthusiam
- Think about transforming the whole enchilada following something like the Agile Fluency Model
- Think Continuous Delivery and work backwards
- Final Thoughts
- Tyler Durden would have made a great Agile transformation coach
- You hire people because you feel that they are capable of doing what has to get done. Make it your job to enable them to do just that.
- Feed your people everything to allow them understand why, what, and when; let them handle the how and who
- Ensure roadblocks are removed from process and infrastructure; remember the Agile Fish
- Insist on Technical Excellence, not process excellence.
- Figure out ways to bring joy back to the workplace.
The actionable items are found in the "How We Should Go About Software Development in an IT Setting" and "Final Thoughts" sections.
For the Agilist whose company isn’t “getting it” this talk is hype-free. No industrialized checklists. You get brutal truths of the problems and actions to solve them. Reclaim Agile!
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Dave Bales - Causal Loop Diagrams: How To Enhance Your System ThinkingDave BalesAgile CoachAgileMe
schedule 2 years agoSold Out!
Popularised in Peter Senge’s The Fifth Discipline, causal loop diagrams provide a diagramming approach to mapping out the cause and effect landscape in a wider system.
The technique seems to have been overlooked in modern times, and yet it is a powerful tool to evaluate and discover virtuous or vicious cycles in the system and trade-off balances between opposing forces.
This technique is much more powerful and yet more subtle than the five whys or other root cause analysis techniques, and looks to map out the upstream causes and downstream effects in a dynamic environment. High-end diagrams can illustrate areas of high pressure that either perpetuate a negative loop (vicious cycle) or a positive loop (virtuous cycle.) This approach has helped me enormously in understanding how to position an Agile adoption that is sensitive the dynamics at play in a program or enterprise landscape, most often when the solution or combination of solutions are not immediately obvious.
This talk will present some simple techniques to help you to use causal loop diagrams to map out your own systems and contexts and become aware of the cause and effects within your landscape.
Josh Godsiff - Move Fast And (Don't) Break Things: Being more agile with Functional ProgrammingJosh GodsiffSoftware EngineerArbor Networks
schedule 2 years agoSold Out!
If you work with developers (or are one), there’s a good change you’ve heard of functional programming – at least in passing. What you may be less familiar with are the benefits and drawbacks compared with other styles such as object-oriented (Java, C#, C++) and procedural (Python, PHP, C) programming.
This talk aims to provide a largely non-technical overview of how functional programming can help teams deliver working software frequently, with greater confidence and flexibility, as well as some of the complexities, drawbacks and paths to adoption.