Hello All,
I have had the opportunity to meet with a number of IT leaders in that last couple of years to discuss with them the adoption of agile practices in their organizations. In all of the meetings I have had I do not remember a time when someone actually overtly disagreed with the concepts of agile and particularly scrum. They have, however, questioned whether agile would work within their particular organization. Agile’s perceived lack of documentation and defined/written processes, simple framework and seemingly ad hoc approach to development have all been cited as going against the grain of their typical organizational practices.
This has made me wonder over the years if agile and particularly scrum is too simple. Is scrum’s perceived lack of rigor an obstacle to adoption by most large companies? Is the simplicity of agile, which makes it such a malleable framework to accommodate change, actually a barrier to adoption?
Many of us older IT practitioners were schooled in practices that had rigorous processes, extensive documentation, detailed quality audits and excessive measurements that have predispositioned us to believe that only complex methodologies will lead to success. It sometimes seemed, in the old days, that the more detailed a methodology, the more trusted and respected it became. I also wonder if in fact IT practitioners created an entire industry around complexity. Let’s face it, the more esoteric the domain, the greater the level of job security for those within the confines of that domain.
So now we are introducing simplicity, perhaps simple enough that “even a caveman can do it.” (I am not suggesting that adopting agile is easy, only that it provides a relatively simple framework that is easy to understand). Is this message a threat to traditionalists? Is the real barrier to adoption one that stems from individual and organizational self preservation? Have we become too comfortable in our minutia that we are unwilling and unable to accept and try alternatives?
As always, I welcome your thoughts and comments.
Happy Sunday!
Pete
I meet a lot of the same resistance with my clients. I see Scrum as a skeletal framework to help an organization meet the values and principles from the Agile Manifesto. Yes it is simple, but I see that as a good thing because you can “fill in the gaps” with practices and principles that make sense for a specific company/team. If a company pushes back on the lack of documentation then se wit down and talk about what value their current level of documentation brings. We’ll walk through all the common reasons for not performing and documenting too much detail up front and for practices to help document the solution afterwards that will not be as perishable. If we do find actual business value in some form of documentation that is not normally practiced in Scrum then we add it into the mix with a keen eye in retrospectives to ensure it is still providing the value we originally thought.
Some adoptions of Scrum will need to be evolved and expanded to fit a particular company’s needs and as long as what we eventually implement is still conforming with the values and principles of Agile that the organization has chosen to adopt then I am all for it. Purists may cry “Scrumbut”, but if the company is seeing improvement, who cares what you call it?
[...] This post was Twitted by t_agile [...]
Thanks for your comment Tommy. I certainly agree.
Pete
I am always fascinated by claims that Agile methods are “too simple.” I think the key words in your bolded sentence are “perceived lack of rigor.” Scrum, and Agile methods in general, are very simple compared to more extensively documented phased, sequential methods.
Yet I see a strong expectation that Agile Values and Principles are applied very seriously. What I see is that people who are not prepared to do this will start, almost immediately, to “tailor” a given method, like Scrum or XP, by coming up with reasons to not do some of the things they ask be done. This is where I see the term “Scrumbut” most often applied, i.e., where the little rigor Agile asks of people cannot even be tried, at least, for a while.
Perhaps it is because of this tendency of people to want to remove whatever rules or strictures are expected that people feel they need more “rigorous” methods. If a great deal is asked, then when people resist some of it, it may be felt that enough will be left behind to keep things under control. To me, this need to have formally declared rigor suggests a lack of confidence that people can impose self-regulation, self-management without sufficient external declaration (and exercise of control.
Evolving and expanding on Agile ideas does not, in itself, seem to me to be surprising. It fits quite appropriately within Alistair Cockburn’s matrix of project risk and complexity where you grow the rigor and formality as both project risk and complexity increase. But you start with a simple structure and allow people to self-organize to determine what additional rigor and formality is needed.
My own “purist” tendency when teams feel they need to change something their chosen Agile method asks them to do is simply to ask them if it preserves (and enhances) the goals/intent of the Values and Principles. I think the “…but” problem occurs when a change is made to Agile practice which loses some aspect of those Values and Principles.
When Agile folks look at any tendency to add more rigor or formality to Agile practices and point to the “simplicity” Principle, I remind them that a well-known expression of that idea is “the simplest thing that can possibly work.” The latter half of that phrase is important. If something needs to be added to truly make the effort “work” and it is the “simplest” additional rigor/formality that can do so, I am not too sanguine about purity.
But it does surprise me, as I note above, that Agile is criticised for being too weak on rigor while people want to “tailor” away the structure that does exist, usually before allowing a decent period of time to pass trying to apply it.
Software development is never simple because the problem of software development is that of implementing an elusive, vague, and constantly changing business value. I don’t believe it matters what you call it or what process you wrap around it. The reason people put in all those gates, documentation, and process in the old days is because people believed that software development was engineering. But, it’s not. It’s more akin to an art form — an interpretive, expressive art form that attempts to take some vague notion of what a customer wants and turn it into a usable, functional, and effective form of business value.
I have heard that software development is like building a house, with blueprints, and bills of material, etc. If people need that kind of comparative visual, then it’s like building a *custom* house at best — and doing it for a customer who will indeed change his mind 10,000 times during the course of development — and all that combined with an architect who will also change his mind several times during the course of development.
The simple truth is this. The process is not “too simple”. People have made too much to-do about the engineering aspect and not nearly enough on the business value side. Scrum is a simple process because there is absolutely NO valid reason to make it so complicated other than to waste time and money. For those that claim Scrum is “too simple”, I say you are in the same position as the scientists of old who thought, for sure, the Earth was flat and also the center of the universe.
Free yourself of the shackles of Cover Your Ass development and start working directly with each other to make your business better. It’s really that simple.
I believe software development is engineering. But it is not production engineering, i.e., manufacturing, which is the model used to develop many of the existing standards and models for software development. What you describe is design engineering which opoerates completely differently than construction forms of engineering.
Read things by Billy Vaughn Koen, Henry Petroski and Don Reinertsen regarding the differencs and what engineers do when they engage in design. In particular, Reinertsen’s book “Managing the Design Factory” deals with this design vs manufacturing issue head on. (Koen talks about engineering heuristics and Petroski talks about how enginneers respond to and seek to mitigate failure.)
Pete, I agree with you that many managers see Agile (and particularly Scrum) as not fitting within their organization. But I wonder if it’s because they fear that Scrum reduces communication between the software developers and the rest of the organization. They express it as needing detailed upfront documentation, progress reports or whatever but it’s more an expression of lack of trust of the developers. Hopefully this is something that will be cured with more experience of the power of Scrum but personally I’d like to see the Agile methodologies focus more on communication with the business.
Fay,
You are right! Nothing replaces communication with the business. No matter what methods you employ. I do believe that Sprint reviews and retrospectives with the team and the Product Owner are a part of that communication, but yes…a more comprehensive program should be investigated.
Pete
Fay, I think part of that problem is solved by… Chickens. Some Scrums discourage a lot of visitors, and I understand the reasons for that, but sometimes the right thing for the business customers to do is just drop by a Standup meeting and listen for a while. At least in my experience.
Amen Dan! Amen.
Thanks,
Pete
For any project manager that relies on continuously updating documentation and being in meetings to justify their existence and job, the outward simplicity of Scrum is a definite threat. While other methods of PM focus on building the team, Scrum’s focus is much greater. Also, Scrum and Agile are outwardly simple, but quite complex in practice. You cannot blindly apply a specific set of practices in a cookie cutter approach, and therein lies the challenge and fun of Agile. Scrum provides an excellent framework within to work, and then gives you the license to figure out the rest for your specific context.
[...] Is Scrum Too Simple? [...]
Scrum’s perceived lack of rigor can be interpreted as shirking the details that developers don’t want to do. “Just let me code” is remembered by older business people as “Just go away and I’ll tell you what you need when I deliver”. Or “Documentation? Well, all the code is Commented.” said to someone who does not have access to review the code. “Agile is the answer” comes through as “Trust me” to the people who are old enough to remember Joe Isuzu ads.
All of the processes and documentation and PM that are anathema to Agile advocates came about because customers had their trust eroded by unusable or useless deliverables from IT teams. Agile adoption doesn’t overcome bad relationships between business and technology – if anything it makes it painfully more apparent.
It should be recognized that customers have ‘skin in the game’ too, and at least one customer rep must be a willing and active ‘pig’. Incremental adoption of Agile – team by team – can be used to re-earn the trust needed while guarding against pitfalls like Scrumbut or flaccid Scrum. Organizations also need to see that deliverables from Agile teams can be implemented, supported and maintained beyond the development lifecycle – more trust earned.