1. 4

    @geshan Your articles seem nicely written and laid out, and with good diagrams and examples, but it’s not clear who they’re useful for, or what your experience level is. This article may be useful for a junior developer working on a single server LAMP app, but for most other people it’s far too simplistic and doesn’t cover interesting migration cases; likely teams will have their own specific environments to plan for and/or will be using libraries/tools that will dictate some of the steps and workflow.

    You may want to focus on an area that you are an expert in, where you can write original content that most people can learn something new from, or if you’re not an expert in a subject you can still write valuable articles by researching and compiling the best current knowledge on that subject. The other option of just writing stuff at a low technical level which is well covered by other content at much more advanced technical levels (e.g. mysql migration practices) even if it’s prettily presented, doesn’t make content that will have a very large or engaged audience.

    1. 1

      Thanks, James, I would keep some of it in mind.

    1. 1

      Definition of ready for development and Done are crucial for team success. Not having these or having unclear ones will hamper the team performance

      Citation needed. Even more, how is debating over definitions useful in this context?

      1. 1

        No citation as such it’s me who came up with it. I think it is know better when its done, thanks :)

        1. 0

          Because these definitions are more like a contract between customer/management and the developer team. The team will not start until they are “ready” and they need the clarity when they are “done”.

          For example, you are probably not ready if you still need some hardware delivered. Is 100% test coverage necessary to be done?

          1. 2

            these definitions are more like a contract between customer/management and the developer team

            This is what makes me wary of getting hung up over the definitions of ready and done, too. “We have come to value customer collaboration over contract negotiation”, and yet here we are quibbling about whether this story is “sprint ready”.

            In my experience, such teams are trying to optimise for speed by outsourcing direction. Come to us when you know what you want to build, they say, and we will quickly come back to you when we know we have built it. I would rather an interaction where we work with the customer to discover solutions to their problems.

          2. 0

            We (at work) have had long discussions about when a task could begun (especially with multiple dev teams, a customer success team as a stakeholder, etc.) Most tasks can be begun as long as any technical dependencies are done, but in some cases it makes no sense to start a task because the recipient (Customer Success, Sales, Marketing, etc.) will not want it before X date or some other criteria, meaning you will have a “stale” story.

            Defining “done” is also important. Is something done when tests pass? When I push the code? When it’s deployed? When it’s been verified by customers? When a month has passed and nothing has blown up? (Last one is stretching it, but you get the point). If you have one developer who measures done by “tests passing” and another who will not close stories until they have the signature from the CTO, your product will never be what you expect at any given time.

          1. 1

            should be based on value delivered to the customer not only the technical aspect

            What if the customer is the developers? E.g., tool refinement.

            1. 1

              They can also understand the value of course. It should be somehow measurable like using code quality tools like codeclimate.

              1. 1

                The boundary for “customer value” is whether they can use it right now. For developers, that means a working library, API or internal service returning correct (live) data. For outside customers it might often involve both UI work and logic before the customer can make use of it.

                It goes very much hand-in-hand with defining “Done” - having code that compiles and passes tests is fine, but if the API endpoint is not hooked up to the code (“I’ll do that first thing next sprint, but the code/story is done”), you have not delivered any value (yet).

              1. 2

                Last week I had a discussion with someone from another project in the company. Said something like “We are not using Agile but classic project management. We release twice a week, not only after each two week sprint.”

                It feels wrong that a non-agile team releases more often than an agile one, doesn’t it? Now, the principles of the manifesto only says “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” The first principle also mentions “continuous delivery” but it is not clear what that means in the context.

                Well, agile or not. We need to automate our release process more…

                1. 1

                  Generally, agree with your viewpoint. As long as the stakeholders and the tech team is happy with work and delivery calling it agile or not is secondary.

                1. 1

                  Welcome to the community! One quick etiquette thing: we don’t use the post body for summarizing or editorializing the content of the link. Generally it’s best to include those things as additional comments on the story.

                  Okay, personal thoughts: I see a lot of posts people make about “Being agile” vs Not Being Agile. I think it’s easy to see the difference. My question: where and why does this break down? Where does it make sense to do a 10 page requirements document? Why do teams wholey committed to Agile feel tempted to write technical stories? I want to know more about the friction we see as we try to reconcile our ideas with reality.

                  1. 0

                    Thanks. I will keep that in mind. It never makes sense to make a 10-page requirement text-only document IMHO. Sometimes things need to be technical tasks (if not stories) like adding a db column can be a task of a bigger story. Breaking it into tasks more than one person can work on it at the same time.

                    1. 3

                      A couple of general cases I can think of are

                      1. When you have legal requirements, like “this must comply with HIPAA”
                      2. If there are objective “correctness” criteria, like developing a compiler for a language with an official specification.

                      There’s other specific cases where you’d have a giant requirements document (security, high assurance, avionics) but those are the ones I think you’d encounter in a lot of circumstances you would not expect a long list of requirements.

                      1. 1

                        Complex legal requirements seem to almost preclude the use of agile, no?

                        1. 3

                          No, I don’t think so. In my experience, requirements are developed iteratively just like software. Even though a process requires traceability between software and requirements, I have yet to find a project where the requirements where done before the coding started.

                          1. 2

                            No, my most recent team was (and is) iterating on fintech within UK Financial Conduct Authority regulations and with ISO27k-compliant risk management, all while keeping to the agile principles.

                            1. 1

                              Nice! Thanks for the data point.

                    1. 0

                      Thanks for all the comments.