Nice start, OP (especially with unclear specs, my personal pet peeve), but you've only hit upon the tip of the iceberg.<p>Just a few other things I call "work prevention" that make good developers appear to be slow:<p><pre><code> - unclear specs
- context switching
- peer review (both giving & receiving)
- code review
- status meetings
- waiting for others to show up at meetings
- others not prepared for meetings (no agenda, etc.)
- unnecessary but enforced standards (stupid, pointless)
- programs locked by other devs (get in line)
- pre-existing technical debt (must be fixed before amended)
- framework can't handle it
- works but won't scale
- can't recreate bug
- platform issue (server, DBMS, etc.)
- environmental issues (test server out of date)
- waiting for server resources (testing)
- waiting for regression tester
- waiting for user acceptance testing
- specs changing during user acceptance testing
- uncontrolled deployment "freezes" (month-end, release schedule)
- noisy office
- meetings when emails would have sufficed
- phone calls when emails would have sufficed
- text messages when emails would have sufficed
- continually changing priorities
- delays in offshore communications
- lack of training (technology)
- lack of training (business subject matter)
- too much training (HR bullshit)
- not enough donuts</code></pre>
"Writing good specs is important" - it's also really really hard.<p>It is all too easy for a developer to blame difficulties on poor specs.<p>But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.<p>It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.<p>You can't do that in a spec. It <i>needs</i> to be a conversation.<p>Agile favours 'Individuals and interactions over processes and tools', and this is too often forgotten when someone is pimping their tool, or blaming their process.<p>Have a conversation, understand what's needed, build good software.
Wholeheartedly true. Vague requirements are definitely the bane of my existence, just this last week I had a massive story I was working on which I implemented only to be told that I misunderstood the story at hand. After pointing out the confusion with the task, product admitted they got the requirements wrong.<p>Don't get me wrong, I like the story format of detailing requirements, in most cases it definitely helps (although I know many developers who dislike the story format), but it is not without its issues. The weak leak is always the product owner writing the wrong stories within a task.<p>In my opinion the biggest contributor to tech debt is NOT lack of stories in tasks or poorly written ones leading to vague requirements (although it doesn't help), it is unrealistic timelines and failing to factor in testing. When people are pushed to achieve a long list of things in a short amount of time, they take shortcuts to get them done which appeases the product owners but leaves some landmines in the codebase waiting to be stepped on.<p>The biggest issue with Agile in my opinion is lack of time devoted to testing. It works on a cycle of "You estimated we can get this much done within this much time" I have never been in a planning meeting that even mentioned testing as part of the normal development cycle, it is always an afterthought when the other big ticket items are done and time is running out. Time for writing tests and testing should be instantly baked into the Agile process (maybe it is and my experience has been unfortunate), this will significantly reduce tech debt.<p>I think the issue with testing and technical debt in my experience has been the fact the places I have worked in like to call themselves Agile, they have the daily standups that always descend into debates and meetings, they have the planning poker events and we do sprints, however they don't fully adhere to the rules of Agile. When you start slipping in extra tasks that were not estimated on or were just added and slip them into the current sprint, that is not Agile. When you start changing deadlines and priorities midway through a sprint, that is not Agile. I think this is a problem that is more prevalent than people realise. There are misconceptions as to what proper Agile is.
I've found that, when building applications for clients, they never know what they really want. I try to explain that writing an application is just like formally documenting your business process.<p>If you don't have the process, then you don't have an application to write.
I have seen huge improvements in quality and productivity by using stories plus wireframes. The first thing a UI dev does is create a quick mockup for feedback from the end user (specified in the story in the blank after "As a ____" Unfortunately implementing this can be a political struggle because it takes a lot of the decisions away from the business and the project manager and hands them to the developers and users.
We learned this the hard way. After months of development we really didn't use (or know) any tools for <i>proper</i> development so we just wrote code in the most disorganized manner possible, which resulted in shipping far apart with poorly written code. After hiring a consultant on the matter, to introduce dailys, user stories, agile and whatnot,... well the world changed for us. Significantly. For the better, of course.
Context switching can be the worst. Particularly when it's caused by "hurry up and wait" brought on by clients.<p>PM: Client wants feature X and they need it now!<p>Developer: Great, I can get started today, but first I'll need clarification on X, Y and Z.<p>PM: I'll e-mail the client...<p>Then hours turn into days, days into weeks. By the time they get back, I've completely forgotten what it was we were going to do on the project or why I needed to know X, Y and Z.
Oooh boy do I hate that style of user story. In my experience it just seemed to degenerate into "as a business owner, I want developers to make this feature so that our product can have this feature".
I don't think specs are ever going to be perfect. Simply because the people typically writing specs (project managers, user experience designers, business analysts etc.) view the requirements through a different lens than a developer.<p>In my experience the best solution is for them simply to be available to the developers to answer questions that arise in a timely manner.
Accurate reporting is great, after "accurate" guestimations. As a 15-year developer, I still get it wrong. Careful planning <i>before</i> you start is so crucial. And my boss knows to take whatever I say, double it, and then add a day. We're finally all on the same page :-)<p>I love the Mad Libs-style form in sprintly, btw.
To me the root cause is generally a lack of resources in terms of time and money. Contributing to that is the general inability for people to grasp the complexity of software development.<p>After implementing the requirements, it is found that they did not reflect the actual desired system. Then there are technical issues that were unforeseen. Rather than accepting these technical issues as additional costs, they are blamed on the developer, "if they knew what they were doing, there would have just done it already". Incorrectly or poorly communicated requirements are also blamed on the developer.
To me the root cause is generally a lack of resources in terms of time and money. Contributing to that is the general inability for people to grasp the complexity of software development.<p>Personally, I have never had a client or budget that I could say was really reasonable throughout. I believe this unicorn may exist somewhere. Certainly I haven't been finding my clients in the most auspicious places.
> it also appears that teams have a hard time transitioning from “done” to “tested and ready to be deployed” (look at Completed to Accepted above).<p>How can it be done if you don't know if it works? It's troubling that it takes a long time to go from 'done' to 'ready to be deployed', when they sound like the same thing.<p>I mean, really it's just terminology, but it suggests that there's a lot of tasks that are not being considered as 'real work' that are actually quite time-consuming in practice. It can be useful to look over what work was actually done historically so that perception of a task matches reality.
Here are a few of the resources I have used in the past to help explain to non-technical folks some of what a developer needs to deal with when involved in a large project.<p>1) Ward Cunningham explains "technical debt":
<a href="https://www.youtube.com/watch?v=pqeJFYwnkjE" rel="nofollow">https://www.youtube.com/watch?v=pqeJFYwnkjE</a><p>2) comic strip - "How Projects Really Work":
<a href="http://www.projectcartoon.com/cartoon/2" rel="nofollow">http://www.projectcartoon.com/cartoon/2</a>
"The second biggest complaint we see from developers? Constantly changing the specs once work has begun." Of course this is called being agile. If everything has to be known before you start work how is this different than waterfall? People don't know what they want or need until they see it. So you have to find some way to let me see it which means writing something based on incomplete information.
Why do they call them "Stories" in this article? Is it because of Agile?<p>They are called "Change Requests". Put on your big boy pants and replace "Stories" with "Changes" and it makes much more sense.
Fail. All of this shows the same problem that "Agile" in general has: it's an attempt to patch closed-allocation, business-driven software engineering. It does not work. Maybe it turns the 0.5x developers into 0.75x players, but it alienates the shit out of the top talent. Fuck user stories. Fuck letting the passengers fly the plane. Fuck "sprints" or "iterations" or whatever nonsense you're calling these artificial time periods. Just let the people who can build great things, and who want to do so, go at it.<p>I agree with some of what's being said here, but not the direction it's heading. Business-driven engineering is a dead end and it can't be patched by hiring consultants to tell people how to play planning poker. If you want to build great technology in-house, you can only do it as an engineer-driven firm.<p><i>The real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is.</i><p>Neat idea. Fails horribly in practice. Why? The problem with "one thing only" management is that the matter of who chooses each person's "one thing" gets <i>horribly</i> political, and fast. "One thing only" works only if the workers get to choose their one thing, which brings us to open allocation, which leaves me questioning whether we need all of this process that the engineers wouldn't impose on themselves...<p>Also, "one thing only" tends to create dead time and throughput issues, (a) due to communication issues and blockages, and (b) because people who'd rather have a different "one thing" will often do other stuff anyway. It also tends to lead to a high burnout rate when people can't <i>voluntarily</i> switch between at least two tasks.