There are so many well-thought out software development (SD) methods. They are laid out beautifully on paper- diagrams of traceability of activities and artifacts to take ideas from users’ minds all the way through product implementation and operation. Together with some templates, guidance, tools, training, and packaged together in a professional way, a software development method is born.
I am not a methodologist, though I love to learn about all kinds of software development methods. They seem to cover all bases. It all makes sense – no more mysteries. Surely when following these steps, I won’t miss a thing! Seeing a detailed method laid out in a process flow diagram gives me comfort. Every artifact I can imagine is documented and approved somewhere. I can see where everything goes from idea to code to product. I will know where we are going wrong every time…The promise of complete knowledge!
So why don’t these methods result in more success?
I have become convinced that 2 major reasons (in addition to the commonly-discussed problems) they don’t result in more success are
- there is just too much ‘method’ in SD methodology. There is too much ’stuff’ to do, and
- by virtue of having steps and artifacts assigned to roles, people are no longer responsible for the product, they are responsible for ’stuff’ – artifacts and steps
Too much ’stuff’
All these steps, all these artifacts – all this stuff. Add all these things to the chaos of every day – last-minute issues, being split across multiple tasks and projects, multiple bosses. Who has time to understand the ‘Spirit’ of the methodology – that which actually is needed to make it work?
Methodologists can look at the RUP, at anything Summit-D based, at PMBoK, at any other heavyweight methodology, and see how many of these methods may actually be customizable…How with some thought you actually might be able to run an Agile project using them! How they may in fact be iterative, despite the linear appearance of the diagrams…
Most people (myself included) are not methodologists. They are people trying to get projects done amidst a host of challenges and distractions. There is little time to invest in understanding how a holistic SD method works, how to customize it, how to somehow iterate on one dimension while performing linear phases on another! Though these things seems simple to methodologists…they are a layer of complexity that most of us on the ground can’t even begin to devote the mental cycles to.
Accountability for Product is Lost
On a project, I am no longer responsible for the finished product. I am responsible for an artifact, during a phase. When the phase is over, and my artifact is ‘done,’ my job is done, and the next step (and eventually, the product itself) becomes someone else’s problem. Successful product development now relies on assumptions like these:
- That my artifacts got the true user requirements right
- That I consumed the last artifacts and interpreted them correctly when creating my artifacts
- That everyone consuming my artifacts interprets properly when they create their artifacts
- That the final product, the result of all of these handoffs and interpretations and translations, is what the user truly requires
- That nothing changes
There are many challenges with these assumptions. If people are not responsible for the finished product, but rather for interim artifacts, is there something lost? Is their expertise available once they hand off their artifacts to others? I believe that something is inherently lost just by virtue of changing any person’s goal from the finished product to any interim artifact.
Agile
I believe that one of the most important unwritten benefits of Agile is that everyone on the team, as a team, is focused on the goal of the end product. Artifacts can be used as tools or as consumables in the achievement of the product. Everyone has the same goal. No one can say ‘it’s not my problem, I completed my artifact.’
‘Hybrid’ Methods
Some very talented methodologists, as the pendulum swings from pure prescriptive methods to pure adaptive methods towards more prescriptive again, propose ‘hybrid’ methods. Get the benefits of both! We can ‘balance agility and discipline’ (inappropriateness of those specific words when comparing Agile and traditional methods is a separate topic) We can benefit from agility while gaining the comfort of our artifacts…panacea. Hybrid methods look great on paper. In practice, I’ve not seen better results – once you start introducing the artifacts as ends themselves – the focus away from the product itself begins. The benefits of the Agile principles quickly fade away.
Consumables, not Deliverables
I like to treat artifacts as consumables or as tools – things that can be used up during the process of creating the end product. The better the quality of these consumables – the more ‘pure’ they are, and the less unnecessary stuff they contain – the easier they will be to process. Artifacts can also be tools (many examples of how can be found throughout the Agile world on the internet) – used as needed when they help teams produce great product.
About George Schlitz
Interesting. I disagree. I think that there is lack of ownership because nobody bothers defining the critical need and primary differentiator in 200 words or less.
This is very true!!!! Two pieces really jumped out at me…The “too much stuff” theory and “Consumables v. Deliverables”…I have found time and time again that “a few words spoken is worth a thousand PRDs”. I.E. There is too much paperwork and not enough face to face contact in most of these approaches which has huge implications. A lot gets lost in translation or worse yet never gets translated at all…In fact this can go on for months or even years!!! This can continue past the release date until the “bug” discovery phase aka new features (aka, the original features that never got fleshed out because people were writing past one another). As psychologically hard to swallow as it may be for many experienced process lovers, a combination of conversations one on one and in groups (depending on the needs at a given point in time) can accomplish far more in a short time than a long document or set of email chains. I am learning that most people are too ADD or think they are too busy or really, more often so, just simply don’t want to read these things (myself included). I think this is human nature not a failure of process or laziness. However, if you start chatting with them, they will talk for just as long as it would have taken to read a PRD and give you all the information you need. Why? Maybe because talking is more fun. People like to hear themselves talk. It is less exhausting…There are probably a thousand reasons. All I know is that it seems to be true time and time again. Also, docs and emails are by definition one sided. One person works on it at a time as opposed to a conversation which is by nature, interactive. Even if you do “paired documentation” which I just made up because I have never seen it done, only one person can really write at a time or if you try to do it together, people get bored, doze off, their eyes get tired staring at the overhead. Usually, someone takes the lead and owns it…It just doesn’t lend itself well to being a group activity or a join effort in the same way that a conversation does and in most cultures it is completely fragmented. If one person isnt owning it, people pass it around and own it for a time period. Also, the efficiency lost during task switching as people keep re-reading a document and grasp and make changes doesn’t come into play when communicating verbally. In addition, the heavy documentation culture has psychological impacts as well. For example, there is often a sterility in the relationships that evolves culturally which is unconscious as well. Again, human nature, not anyone’s fault. When people are isolated from each other regularly staring at their screens and prepping for sign-offs, the collaborative mood just doesn’t come to life. As you alluded to, this culture promotes the mine and yours mentality. Another thing you mentioned was “consumables versus deliverables”. I think I am seeing why this is hard for many cultures to adapt. Again,t human nature at work. Like you said, too much stuff…I have seen it over and over again with all company sizes and between a variety of personality types. When people invest a lot of work and time into long detailed documents, they naturally develop a sense of pride in their work and an unconscious need to legitimate the value of what was produced even if what they are trying to say could be communicated more easily and effectively via a few words and some face to face contact. Naturally, this investment creates a ball and chain effect because a person or team becomes attached to the documentation and teams stop asking why are we using this and is this working? Even if only the author has bought into it, others will pretend to play along but unconsciously ignore it to some extent. Or the team buys in but no one is really on the same page about what it all means. And psychologically, the further down that road a person or a team or a company gets, the harder it is to admit that there is an easier way. It’s funny actually. I just had an experience like this at my new job where I started this week. Someone wrote a doc on their own for a big upcoming project based on their limited knowledge. They still need a bunch of info that is locked in other peoples heads…They have tried for weeks to get everyone to read it but people sort of blew it off. And the project hasn’t started yet. I threw together an informal kickoff meeting, humored the author by attaching the document to the invite, but asked everyone to think about what they want to accomplish in three feature areas. Then I ran around talking to all the attendees about the upcoming meeting asking them questions under the guise of being new but mostly my motive was to get them to think about what they should be preparing to ask and contribute in the meeting. I communicated various things between people and asked everyone to individually come up with a short list of things they want to make sure to cover just for their own notes to bring with them and restated the goal of the meeting as a kickoff to come up with an initial set of features. I told the doc author I promised to get whatever comes out of the meeting into his document once we have a better understanding. Hopefully they have done their mental prep work just by talking about it all out loud. When we get together as a team, they can talk to each other efficiently to understand the requirements collaboratively since really no one has bought into that goal before now when the doc was circulating via email. I noticed that it was easy to talk to people and share information across group members in a short time running around. I also noticed that people started to own a share of the preparation simply by being asked questions and being told what the goal of the meeting was in a vague and open-ended way, without reference to specific documents. I am looking forward to seeing how that progresses.
I guess the point of all that was to say I agree with you!!! And…Selfishly to hone in on one of my very specific pet peeves in the “too much stuff” category which is death by the written word! I hope your site will let me post this verbose reply!!! Perhaps it is “too much stuff”
Thanks for your comments! I am not sure I understand the first, and would like to hear more.
I agree and have had similar experiences to Amy’s…