The Enterprise is a Curmudgeon
- by John K. Hines
Working in an enterprise environment is a unique challenge. There's a lot more to software development than developing software. A project lead or Scrum Master has to manage personalities and intra-team politics, has to manage accomplishing the task at hand while creating the opportunities and a reputation for handling desirable future work, has to create a competent, happy team that actually delivers while being careful not to burn bridges or hurt feelings outside the team. Which makes me feel surprised to read advice like:
" The enterprise should figure out what is likely to work best for itself and try to use it."
- Ken Schwaber, The Enterprise and Scrum.
The enterprises I have experience with are fundamentally unable to be self-reflective. It's like asking a Roman gladiator if he'd like to carve out a little space in the arena for some silent meditation. I'm currently wondering how compatible Scrum is with the top-down hierarchy of life in a large organization. Specifically, manufacturing-mindset, fixed-release, harmony-valuing large organizations. Now I understand why Agile can be a better fit for companies without much organizational inertia.
Recently I've talked with nearly two dozen software professionals and their managers about Scrum and Agile. I've become convinced that a developer, team, organization, or enterprise can be Agile without using Scrum. But I'm not sure about what process would be the best fit, in general, for an enterprise that wants to become Agile. It's possible I should read more than just the introduction to Ken's book.
I do feel prepared to answer some of the questions I had asked in a previous post:
How can Agile practices (including but not limited to Scrum) be adopted in situations where the highest-placed managers in a company demand software within extremely aggressive deadlines?
Answer: In a very limited capacity at the individual level. The situation here is that the senior management of this company values any software release more than it values developer well-being, end-user experience, or software quality. Only if the developing organization is given an immediate refactoring opportunity does this sort of development make sense to a person who values sustainable software.
How can Agile practices be adopted by teams that do not perform a continuous cycle of new development, such as those whose sole purpose is to reproduce and debug customer issues?
Answer: It depends. For Scrum in particular, I don't believe Scrum is meant to manage unpredictable work. While you can easily adopt XP practices for bug fixing, the project-management aspects of Scrum require some predictability. My question here was meant toward those who want to apply Scrum to non-development teams. In some cases it works, in others it does not.
How can a team measure if its development efforts are both Agile and employ sound engineering practices?
Answer: I'm currently leaning toward measuring these independently. The Agile Principles are a terrific way to measure if a software team is agile. Sound engineering practices are those practices which help developers meet the principles. I think Scrum is being mistakenly applied as an engineering practice when it is essentially a project management practice. In my opinion, XP and Lean are examples of good engineering practices.
How can Agile be explained in an accurate way that describes its benefits to sceptical developers and/or revenue-focused non-developers?
Answer: Agile techniques will result in higher-quality, lower-cost software development. This comes primarily from finding defects earlier in the development cycle. If there are individual developers who do not want to collaborate, write unit tests, or refactor, then these are simply developers who are either working in an area where adding these techniques will not add value (i.e. they are an expert) or they are a developer who is satisfied with the status quo. In the first case they should be left alone. In the second case, the results of Agile should be demonstrated by other developers who are willing to receive recognition for their efforts.
It all comes down to individuals, doesn't it? If you're working in an organization whose Agile adoption consists exclusively of Scrum, consider ways to form individual Agile teams to demonstrate its benefits. These can even be virtual teams that span people across org-chart boundaries. Once you can measure real value, whether it's Scrum, Lean, or something else, people will follow. Even the curmudgeons.
