{"id":827,"date":"2016-02-14T16:47:47","date_gmt":"2016-02-14T16:47:47","guid":{"rendered":"http:\/\/www.seonthemon.com\/wp351\/?p=827"},"modified":"2017-03-05T18:02:45","modified_gmt":"2017-03-05T18:02:45","slug":"process-much-ado-about-little","status":"publish","type":"post","link":"https:\/\/www.seonthemon.com\/wp351\/2016\/02\/14\/process-much-ado-about-little\/","title":{"rendered":"Process is very often, much ado about little"},"content":{"rendered":"

The first principle in the Agile Manifesto<\/a> is “Individuals and Interactions, over processes and tools”. A recent development task illustrated that point starkly – skill trumps process<\/em>.<\/p>\n

Time’s a wastin ….<\/h2>\n

I was working through a weekend, exhaustively specifying the UI (mockups, WORD docs, UML State diagrams) for a recent user story, when it occurred to me that we were wasting our time.<\/p>\n

Here is more or less the user story I was working on.<\/p>\n

As a documentation processor, I must be able to review all of the documents in a mailbag. Upon review, I must be able to accept, or reject each of these documents.<\/p><\/blockquote>\n

In the time that it was taking to describe the UI to its last gory detail, \u00a0I could create a working prototype of the UI, which would be close to 80% of what the user needs. \u00a0The business folks could take the prototype for a spin, and give me feedback, which could quickly iron out the remaining 20% of the work.<\/p>\n

See, we are building this for processors in an insurance company. \u00a0 They are not looking for sophisticated, space age UI. \u00a0They just need something that is easy to understand, learn, and allows them to do the work efficiently.<\/p>\n

Between the business analyst and me, we could have the UI squared away in a couple of weeks – a single sprint. \u00a0Add a tester if you must.<\/p>\n

I will test every damn line of code I write anyway, before this leaves my hands. \u00a0 The tester is only a second line of defense. \u00a0 Even without that tester, I can get this very close to done.<\/p><\/blockquote>\n

So why am I specifying the UI when I can just build the thing myself? \u00a0I am having to do this because, collectively, the primary resources that are assigned to this task cannot or will not, produce an effective UI on their own. \u00a0That amazes me. \u00a0I am shaking my head as I write this. \u00a0 If you have several years of experience with this problem domain, with these business analysts, with these end users, and with the same UI technology, you should be able to take the user story, fill in all the missing details, and end up at the UI.<\/p>\n

Again, here is the user story, for reference.<\/p>\n

As a documentation processor, I must be able to review all of the documents in a mailbag. Upon review, I must be able to accept, or reject each of these documents.<\/p><\/blockquote>\n

Let’s think through this.<\/p>\n

Analysis<\/h2>\n
    \n
  • Users have to review all the documents in the mail bag.\n
      \n
    • This means you have to list the documents to the user<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
        \n
      • So how do you present a list of documents.\n
          \n
        • A table, where each column is some attribute of the document, and each row is a document.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
            \n
          • How do you make it easy for a user to study a large list of data that is in a table?\n
              \n
            • Allow filtering and sorting by various attributes.<\/li>\n
            • Break up the list into several pages, and allow the user to page\n
                \n
              • Or simply allow the user to scroll up and down the large list.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
                  \n
                • How do you help the user make changes to large amounts of data safely, and correctly?\n
                    \n
                  • You must ask the user to confirm a large change. \u00a0Give her a chance to back out.<\/span><\/li>\n
                  • You must provide the user a way to undo a change. \u00a0Mistakes will happen.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
                      \n
                    • What attributes (columns) of the documents must be included in the list\n
                        \n
                      • Leave out the attributes of the documents that are implementation-centric, which users have no need to know.<\/span><\/li>\n
                      • Pick the attributes that are business information. \u00a0Make a guess on which of these the user might be interested in. \u00a0 Changing this list after review should not be hard.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                        Can’t the developer do this?<\/h2>\n

                        Analysis<\/h3>\n

                        If you have been developing UI for any time at all, you should be able to do the analysis I just did, and arrive at a similar, if not the same place.<\/p>\n

                        Business Info<\/h3>\n

                        You have been working in this domain for several years. \u00a0That means you must already have all the business information you need.<\/p>\n

                        You must know the business-centric attributes that characterize the mailbag and documents. \u00a0 These become the columns of your listing, and suggest what the user can sort and filter on.<\/p>\n

                        Language and jargon that end-users will recognize must also be familiar to you by now. \u00a0This is where static labels, feedback messages and such will come from.<\/p>\n

                        Implementation<\/h3>\n

                        You have been working with your UI framework for several years. \u00a0So you should know how to implement the various UI features mentioned above – a table of data, sorting, filtering, paging, scrolling.<\/p>\n

                        But none of this happened<\/h2>\n

                        But none of this happened, and a UI designer had to be brought in to spell everything out. \u00a0 Why?<\/p>\n

                        The Developer<\/h3>\n

                        Though they were well-versed with the UI framework, the developers have little knowledge of, or interest in, what makes an effective UI.<\/p>\n

                        They are happy to be told what to build. \u00a0They want to be told what to build. \u00a0When left to their own initiative earlier, they produced a UI that so defied common sense and business reality, that the end-users’ job turned into a labor-intensive, error-prone, hell.<\/p>\n

                        The Tester<\/h3>\n

                        If the testers know the lingua franca of the business (English, in this case), if the testers know the business, and if they know the end-users, the testers can judge if the UI satisfies the business need, simply by relying on the 2 sentence user story.<\/p>\n

                        Unfortunately, testers’ familiarity with the business is uneven. \u00a0They are simply kids that compare a spec to delivered software. \u00a0If the spec is incomplete, or incorrect, these testers are thrown off course.<\/p>\n

                        Further, more often than not, the testing leadership subscribes to the view that testers must only work off an exhaustively detailed spec. \u00a0Applying their own knowledge of the business, their own analytical and communication skills, is considered risky. The focus on learning the business themselves is weak.<\/p>\n

                        Manager<\/h3>\n

                        Well, managers have all the power, which makes them responsible for everything, doesn’t it?<\/p>\n

                        Who are they hiring?<\/h4>\n

                        The UI developer does not exhibit knowledge of effective UI design. \u00a0 \u00a0So how did we end up hiring him?<\/p>\n

                        Say the manager that is evaluating the developer does not know anything about UI design himself. \u00a0 So the manager cannot determine the developer’s competence in the matter. \u00a0That is reasonable and common. \u00a0 A manager is constantly confronted with problems in which he does not have direct expertise. \u00a0 Yet, she must hire people that will be responsible for solving that problem. \u00a0 \u00a0In that situation, a manager has to be able to recognize competence (and conversely, incompetence) as a characteristic separate from concretely observable skill. \u00a0 Competence has an aura, a body language, a speech pattern, a look in the eye, as does incompetence. You have to be able to smell the bullshit before you see it.<\/p>\n

                        When managers neither have concrete expertise, nor do they have a nose for fakery, we end up with these half-baked developers that require to be spoon fed.<\/p>\n

                        Bad drivers<\/h4>\n

                        Many resources are able to learn and do more if we create the right environment. \u00a0This is usually some combination of large grained carrot and stick, coupled with the pushing of buttons that we can only learn by getting to know the resource personally.<\/p>\n

                        Effective UI design for the corporate world, is a skill that can be learned by just about anyone in a few weeks, or over the course of a few UI development tasks. \u00a0If a developer has worked on UI development for going on three years, and still does not have a coherent, useful view of the matter, the leadership has been asleep at the wheel.<\/p>\n

                        The same argument applies to the testers. \u00a0 The management enabled them to be unthinking, ‘garbage in garbage out’ type grunts.<\/p>\n

                        Skill trumps process<\/h2>\n

                        What a business analyst and a skilled engineer can take care, is now distributed over a whole platoon – The business analyst, the UI designer, the developer, the tester, tech and test leads to oversee the grunts, managers to oversee all of this.<\/p>\n

                        Where the work could simply be a conversation between two people, now is a multi-step workflow involving many more people than that. \u00a0Two people getting a task done is just work<\/em>. \u00a0 \u00a0Eight people, each with their own inputs, and deliverables, working on narrow parts of the whole, and that with their vision constrained by blinders, is a process<\/em>.<\/p>\n

                        What does the process<\/em> buy us? \u00a0 Nothing that I can see. \u00a0I see overhead. An 8 to 10 person team requires more management and book-keeping than a 2 person team. I see a machine with more moving parts, which exponentially increases the complexity, the amount of co-ordination required, and the number of ways the process<\/em> can fail.<\/p>\n

                        One or two committed, skilled engineers can replace the whole process<\/em>. Why not learn to identify, hire and hold on to such resources? Why the fixation on process<\/em>? Do you want get work done?<\/em> \u00a0Or do you want to run a process?<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

                        The first principle in the Agile Manifesto is “Individuals and Interactions, over processes and tools”. A recent development task illustrated that point starkly – skill trumps process. Time’s a wastin …. I was working through a weekend, exhaustively specifying the UI (mockups, WORD docs, UML State diagrams) for a recent user story, when it occurred […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4,1],"tags":[39,42,8,41,18],"_links":{"self":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/827"}],"collection":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/comments?post=827"}],"version-history":[{"count":10,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/827\/revisions"}],"predecessor-version":[{"id":867,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/827\/revisions\/867"}],"wp:attachment":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/media?parent=827"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/categories?post=827"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/tags?post=827"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}