30 Matching Annotations
  1. Nov 2020
    1. Third, you can create value in any span of time. If we see our work as creating these intermediate packets, we can find ways to create value in any span of time, no matter how short. Productivity becomes a game of matching each available block of time (or state of mind, or mood, or energy level) with a corresponding packet that is perfectly suited to it.

      The Intermediate Packet approach ensures you are delivering value after every iteration, regardless of size

      You no longer need to rely on large blocks on uninterrupted time if you focus on delivering something of value at the end of each block of time.

    1. Scrum-Based Learning Environment: Fostering Self-Regulated Learning.

      Linden, T. (2018). Scrum-Based Learning Environment: Fostering Self-Regulated Learning. Journal of Information Systems Education, 29(2), 65–74.

    1. An Agile Framework for Teaching with Scrum in the IT Project Management Classroom

      Rush, D. E., & Connolly, A. J. (2020). An Agile Framework for Teaching with Scrum in the IT Project Management Classroom. Journal of Information Systems Education, 3, 196.

  2. Oct 2020
  3. Aug 2020
    1. "Off-line" vs "On-line". The RAT's focus is to get to a final state, and then ship it, all at once. During the working process, the thing we're working on is "off-line". It's not in the field and no one is using it

      This is a common problem when trying to do agile with enterprise clients.

      Can end up in a bubble where we are working on requirements that have been passed down - from how long ago? and then take even longer until users are actually using it.

  4. May 2020
    1. managing yourself and others.

      Authors promote two ideologies.

      1. Managing Self: The Five Eds (well, first Three) from Agile Leadership by B. Joiner
      2. Managing Others: at its base is Dave Pink's Drive model: Autonomy, Mastery and Purpose. Authors then go to explain some ways of achieving each of previous.
  5. Apr 2020
    1. Spikes Spikes are a type of exploration Enabler Story in SAFe. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate. Like other stories, spikes are estimated and then demonstrated at the end of the Iteration. They also provide an agreed upon protocol and workflow that Agile Release Trains (ARTs) use to help determine the viability of Epics. Details Agile and Lean value facts over speculation. When faced with a question, risk, or uncertainty, Agile Teams conduct small experiments before moving to implementation, rather than speculate about the outcome or jump to a Solution. Teams may use spikes in a variety of situations: Estimate new Features and Capabilities to analyze the implied behavior, providing insight about the approach for splitting them into smaller, quantifiable pieces Perform feasibility analysis and other activities that help determine the viability of epics Conduct basic research to familiarize them with a new technology or domain Gain confidence in a technical or functional approach, reducing risk and uncertainty Spikes involve creating a small program, research activity, or test that demonstrates some aspect of new functionality. Technical and Functional Spikes Spikes primarily come in two forms: technical and functional. Functional spikes – They are used to analyze overall solution behavior and determine: How to break it down How to organize the work Where risk and complexity exist How to use insights to influence implementation decisions Technical spikes – They are used to research various approaches in the solution domain. For example: Determine a build-versus-buy decision Evaluate the potential performance or load impact of a new user story Evaluate specific technical implementation approaches Develop confidence about the desired solution path Some features and user stories may require both types of spikes. Here’s an example: “As a consumer, I want to see my daily energy use in a histogram so that I can quickly understand my past, current, and projected energy consumption.” In this case, a team might create both types of spikes: A technical spike to research how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data A functional spike – Prototype a histogram in the web portal and get some user feedback on presentation size, style, and charting Guidelines for Spikes Since spikes do not directly deliver user value, use them sparingly. The following guidelines apply. Quantifiable, Demonstrable, and Acceptable Like other stories, spikes are put in the Team Backlog, estimated, and sized to fit in an iteration. Spike results are different from a story because spikes typically produce information rather than working code. They should develop only the necessary data to identify and size the stories that drive it confidently. The output of a spike is demonstrable, both to the team and to any other stakeholders, which brings visibility to the research and architectural efforts, and also helps build collective ownership and shared responsibility for decision-making. The Product Owner accepts spikes that have been demoed and meet its acceptance criteria. Timing of Spikes Since they represent uncertainty in one or more potential stories, planning for both the spike and the resulting stories in the same iteration is sometimes risky. However, if it’s small and straightforward, and a quick solution is likely to be found, then it can be quite efficient to do both in the same iteration. The Exception, Not the Rule Every user story has uncertainty and risk; that’s the nature of Agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. Thus, in one sense, every user story contains spike-like activities to identify the technical and functional risks. The goal of an Agile team is to learn how to address uncertainty in each iteration. Spikes are critical when high uncertainty exist, or there are many unknowns.  
  6. Mar 2020
    1. Agile Procurement Alter procurement methodologies to favour agile approaches over “spec and deliver”. Specifically, current methodologies follow a “spec and deliver” model in which government attempts to define a full spec up front and then seeks solutions that deliver against this. The spec and deliver approach greatly diminishes the value of open source - which allows for rapid iteration in the open, and more rapid switching of provider - and implicitly builds lock-in to the selected provider whose solution is a black-box to the buyer. In addition, whilst theoretically shifting risk to the supplier of the software, given the difficulty of specifying software up front, it really just inflates upfront costs (since the supplier has to price in risk) and sets the scene for complex and cumbersome later negotiations about under-specified elements. Instead, create an agile procurement stream in which, rather than detailed requirements being set up front, you secure estimated budget for an initial phase and seeks bids on X number of sprints (with ability to end after any sprint). This model requires acceptance of some budget uncertainty: the total cost of delivery of software may not be fully known in advance. However, one can, alternatively, fix a budget and accept some uncertainty over features delivered. We emphasize that this limitation is not a limitation of open source but of software in general. As the maxim goes: in software development you can have any two of features, time and budget – but not all three. Traditional tendering with its fixed requirements, fixed timeframes – and implicitly fixed costs – exists in an illusory world where one can have all three and implicitly imagines that buying software is like buying traditional goods like chairs whose features, usage and cost are all well-known up front.
  7. Nov 2019
  8. Sep 2019
    1. A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.

      "actively seeks"

    1. The Agile Software Development Process – How We Do It

      To get your tech startup going you have to deal with a lot of challenges, and come through it unscathed. Otherwise, the failure to deal with those challenges may directly lead to mistakes and problems during the actual software development process- hampering your chances of scaling your development process.

  9. Apr 2019
    1. People-centric means that you will allocate specific people to focus primarily on the maintenance tasks,

      approach 1

  10. Feb 2019
    1. INVEST

      According to this checklist, a User Story should be:

      Indepedent (of all others)

      Negociable (not a specific contract for features)

      Valuable (or vertical)

      Estimable (to a good approximation)

      Small (so as to fit within an iteration)

      Testable (in principle, even if there isn't a test for it yet)

      Source(s):

      1. Glossary: INVEST - Agile Alliance
      2. INVEST at XP 1-2-3 by Bill Wake
  11. Oct 2018
  12. Jun 2018
    1. AN EQUITABLE ITERATION PROCESS“Fail faster” is a maxim of application developers these days. It means putting something out into the world quickly and responding to user feedback in future iterations. This is a great way to optimize the value of your application to your users, by starting with something simple and experimenting until you get the right features.Unfortunately while this process can increase positive impacts, it does nothing to diminish negatives impacts. The fail faster approach experiments not only with features but also with the lives of people using those features. Consider the release of the Alexa app for Amazon Echo, which did not allow for blocking calls or texts. This raises immediate red flags for anyone who has been doxed or stalked, and may have directly lead to harm for Alexa users. It isn’t enough to iterate features in response to harm — we must also iterate the process that lead to those features being released. What would that process look like if it was centered around the privacy and security of survivors of violence? Of people from communities that are regularly subject to state surveillance?
  13. Nov 2017
    1. Individuals and interactions over processes and tools

      Do not give up personal interaction in favor of a tool-supported process. "Když tomu nerozumím, tak se jdu zeptat."

  14. Aug 2017
    1. To get low-touch, high-return in your content quality and accuracy, you and your team need to rely on the 5 values of Scrum: openness, courage, respect, focus, and commitment.
    1. Agile relies on communication between individuals during the overall process of development; working software is considered the best measure of team activities, and changes in customer's requirements are always welcome. Software is produced in iterative way: it is released once in a small period of time and every release includes new features.
  15. Jul 2017
    1. This third research question led to the formulation of agile text mining, a new methodologyagile textminingto support the development of efficient TMAs. Agile text mining copes with the unpredictablerealities of creating text-mining applications.
    1. In Agile development we actually conjoin these two tactics. During a development “iteration” where we build several user stories some may be adding new functionality incrementally, others may be iterating to improve, change, or remove existing functionality.

      Con l'approccio incrementale aggiungiamo un pezzo alla volta, per incrementi successivi, le funzionalità che compongono il sistema. Scegliamo prima le funzionalità a maggior valore.

      Con l'approccio iterativo adottiamo una strategia esplorativa, con lo scopo di avere feedback su quello che abbiamo costruito, e cambiarlo in base a quello che apprendiamo nel validarlo, per successive iterazioni.

      Nel caso del sw, l'iterazione serve per migliorare (raffinare), cambiare o rimuovere le funzionalità esistenti.

  16. May 2017
    1. Every time a customer service assistant shrugs and says “computer says no” or an organization acts in crazy, inflexible ways, odds-are there’s a database underneath which has a limited, rigid view of reality and it’s simply too expensive to fix the software to make the organization more intelligent. We live in these boxes, as pervasive as oxygen, and as inflexible as punched cards.

      Isn't it interesting how the rigidity of institutionalised "old economy"-businesses and their management structure as well as their work ethics is, in a way, mimicked by their IT-architecture? Efficiency over effectiveness, stability over flexibility, repetition over creative destruction and innovation. And then came Agile...

  17. Jul 2016
    1. Pages 7-8

      Rockwell and Sinclair talk here about developing an “agile hermeneutics” by which they mean an approach to fast/extreme writing. An example of this is that they tried to write a short essay in one day from the initial research but they also do things such as working in pairs with one person typing and the others talking things through.

  18. Jun 2016
    1. Also, the more complex a software project becomes, the more work you have to put into and it grows exponentially. So, keep it simple and make it fast. It's much easier to write software, throw it away and start over again quickly, than having this huge generic system that tries to do everything. It doesn't make sense. It's just too much work. You'd get this huge software system with thousand dependencies and, in the end, it's really hard to innovate, get new stuff in there, or, the worst case, to change the concept. Almost every software that we have published is not generic but is used only for one case. So, keep it simple and get a prototype in under three days.

      Agile visualization its a worthy exception to this trend. It is generic while being flexible and moldable. My first projects start with an easy prototype in a week and became full projects in a couple of months average. Then I can reuse the visual components by using abstraction and making visual builders.

      The couple of months average included the learning of the programming language and environment, the data cleaning and completion. With the builders the time has started to decrease exponentially.

  19. May 2016
  20. Jun 2015
    1. You should suspect motivated stopping when you close off search, after coming to a comfortable conclusion, and yet there's a lot of fast cheap evidence you haven't gathered yet—Web sites you could visit, counter-counter arguments you could consider, or you haven't closed your eyes for five minutes by the clock trying to think of a better option. You should suspect motivated continuation when some evidence is leaning in a way you don't like, but you decide that more evidence is needed—expensive evidence that you know you can't gather anytime soon, as opposed to something you're going to look up on Google in 30 minutes—before you'll have to do anything uncomfortable.

      Keeping these suspicions in mind, how should we improve agile decision making?