It's Both
Joshua Kerievsky ????
Helping organizations deliver better software sooner | Dad | CEO | Entrepreneur | Author | International Speaker | Software Designer | Tennis Player
There's quite a bit of noise around perspectives that say "Do this" or "Do that" yet much of the time, I find that both ideas have relevance. Here's a short list of areas where "both" ideas are better than one or the other:
I don't recommend working exclusively in open spaces and I don't recommend working exclusively at individual desks. I recommend both. I call it Commons and Caves. Commons is where a group can work together and caves are where individuals can work solo.
I don't recommend mobbing/pairing or working solo all-of-the-time. I recommend both, choosing which is appropriate given the work in question.
I don't recommend only hiring and working with local people in a physical office and I don't recommend only hiring remote people and having everyone work remote. I recommend both. At Industrial Logic, we have local staff and remote staff. They are all quite good and whether they are local or remote, I'm glad they are part of the company.
I don't recommend only using agile methods for all work. Some work is so basic and so predefined, that waterfall is actually a good fit, provided that you build quality in. Again, it's both.
I don't recommend only listening to your customers to decide what to build. You also need to understand what the customer isn't asking for but badly needs. Again, it's both.
I don't recommend only writing clean code. Some code should be quick-n-dirty because it's an experiment and until you learn from it, there's no point in investing in finely-crafted code or tests. It's both (I spoke about this at length in a series of posts called "Sufficient Design.")
I don't recommend having one person solely responsible for deciding what to build. You've got intelligent people on your team. Harness their intelligence! Make it crystal clear that all product ideas about how to make customers awesome are welcome.
I don't recommend only protecting yourself and your interests at work. Your customers, your colleagues, your team, your department and the organization have needs as well. Consider ways to be inclusive in what and who you protect.
I don't recommend only focusing on a team's performance. Individuals also need feedback and guidance on their performance so they can grow and improve. It's both. (And to be clear, I am talking about helping teams and individuals improve, not reporting on individual velocity or productivity).
I don't recommend only having cross-functional teams. You also need a team or two that look across all of the work of cross-functional teams and finds areas of duplication or needless complexity that can be removed. It's both.
What else is both? What can you add to this list so we can stop being so polarized and embrace all good ideas, in context?
Senior Software Engineering Manager
6 年I don't recommend to have no estimates at all, but I also don't recommend estimating everything all the time. Don't waste any time on estimating when you know what is important and you know you can afford and want to build something anyway. It's fine to spend some time estimating when you are still figuring out your priorities and want to get some feeling of how big the challenge in front of you might be. It is fine to use estimates to to form a ball park educated guess whether ROI is even possible when your company's developments are driven by budgets.
Software Development Leadership
6 年1: Structure and process vs. creativity and experimentation. Our teams love to experiment and try new ideas, but there are times when sticking to what we know is the most prudent choice for efficiency, speed, or simply because the initiative is well-trodden territory for us. 2: Fun, exciting and dangerous vs. dull and boring. We make it a point to make every initiative as “boring” as possible over time by discovering all the unknowns and settling all the serious choices as early as possible. So we like our work to be both, but at different times. If it means we’ve eliminated the big risks, “dull” can feel pretty darned splendid! 3: Bikinis vs. parkas. Either one can be the ideal choice or fabulously stupid. The tip-off is on your itinerary, right after the word: “Destination.
Senior Software Engineering Manager
6 年I don't recommend only using agile processes and I also don't recommend only using traditional project / product processes, like PMBOK only. Most agile processes provide implicit implementations of what PMBOK provides explicitly. The danger of implicit is that people 'forget' about it and don't pay attention to important things, like chartering, risk management, stakeholder management etc. While there are many good practices in agile, there are also still very good and highly needed practices in more traditional ways of working.
Senior Software Engineering Manager
6 年I don't recommend using one way of working for everything all the time, but I also don't recommend mixing different ways of working regularly. Switching based on context is fine, but it can also be very disruptive for teams. If you need to switch often, something is wrong. Lack of focus & clear objectives? Try chartering first.
#GovCom Influencer/Community Builder/Human Speakeasy for talent
6 年kanban & scrum! go together like PB&J... :D?