I just completed a Design Patterns Explained course yesterday. It was awesome. The people attending there will never look at design (of any kind) the same and greatly enhanced their ability to write robust code in Agile and non-Agile environments. The information was not new, nor is it hard to find. It’s been published in our Design Patterns Explained: A New Perspective on Object-Oriented Design 2nd Edition since 2004. What hit me was the breadth and depth of material that is available to folks.
Why is this significant to me? Because it illustrates that even though we see a lot of bad code out there it doesn’t mean it has to be that way. I think this is true for all areas of software development. For the last dozen years I have been hearing about how hard it is to do Agile software development at Scale. For whatever reason there has, and continues to be, a large contingent in the Agile software development community that insists their methods will work, if we’d only do them correctly – that the difficulty is that software development is complex and that this complexity makes it difficult to do it well. But the evidence and theory available belay this. The challenges to effective software development somewhat lies in the lie of complexity – that software development itself, is complex. It isn’t. It’s getting people to do it that’s complex. This distinction is essential because without it one tends to not look for the methods that one needs to enable effective software development.
Getting people to learn and actually use proper methods is not easy. Organizational development is complex. But it’s much more likely to happen when one provides the organization you are trying to develop the right insights on how to get their job done. These include:
Here’s a little more information on each of these:
Discovering, identifying, sizing and prioritizing the right work to be done. This is the beginning of proper product portfolio management. We have a lot of information. Check out our BDSD Session 2: Product Portfolio Management on our Business Resources Page. Or, learn how to do it in our Business Product Owner course.
Coordinating work from the begging of its development through its deployment and consumption. One needs to understand flow (Lean) and Kanban to do this. See Scaling Agile with Multiple Teams from our Business, Management and Team Process / Team Technical Webinar Series or take our Lean-Agile Project Management Certification course. The Scaled Agile Framework (we’re certified in this as well) also provides insights here.
Understanding what needs to be built before it is built. This one is easy – learn Acceptance Test-Driven Development or Behavioral Driven Development. Look in our test/validation resources for section for a webinar on ATDD.
Providing teams the proper tools to be able to build software iteratively. Scrum within a context of Lean is very powerful but rarely seen. Kanban with or without iterations is effective here as well. Register for Team Agility: Scrum, Kanban, XP – The Essence of All Three in our Lean-Agile at Scale and at the Team: The Value Steam Webinar series to learn more. You can also watch Lean-Agile: the Next Generation of Agile to see why moving forward with Lean and Kanban to improve Scrum is essential.
How to do Agile analysis of complicated problems. This is part of our design patterns course that started this blog. It includes Commonality Variability Analysis and the Analysis Matrix. See our How to Use the Technical Agility Resources Section for information on these.
How to create robust application architectures and quality code. Want to be able to write effective, robust, easily maintainable code? Use a combination of TDD, refactoring and design patterns. Read Emergent Design, take our Emergent Design Course, watch a webinar on Software Design in the Agile Age or look at our Sustainable Test-Driven Development site for more.
How to do software development well is known. Not just by us, but by several others. The patterns of challenge in the community now (Agile working at the team level but not at the organizational level) point to the fact that most folks have not learned organization wide methods but are still using first generation Agile methods that only indirectly address organizational challenges.
If you are having troubles implementing Agile in the manner you feel possible, I implore you to look for proven methods that work. Please contact me personally (alshall AT netobjectives.com) if you are interested.
Alan Shalloway, CEO, Net Objectives.