AgileMD

agilemd

The web has developed into a terrible place. First, it’s no longer as fun and colorful as it once was, despite . Secondly, all promises that one day we will have a nicely controlled way to quickly create highly performant websites has never been fulfilled. And it is getting worse. my best efforts Wait… What? Don’t we have highly sophisticated and fast frameworks? Like React? Well, they are making it worse. Or, as Alex Russell put it in his magnificent that has heavily inspired this post and that you should absolutely read: blog post It’s not healing, and it won’t be enough to nurse the web back to health, but tossing the Vercels and the Facebooks out of polite conversation is, at least, a start. Alex Russell Do you remember the promise of SPAs (Single Page Applications)? Our pages would become so much faster and more responsive in no time! Yet, has a slightly higher score than reactjs.org. The first page is from 2001, was built by a single person using html3.1, and is probably hosted on a virtual server somewhere, whereas reactjs.org was built in 2023 and uses all the latest and greatest, like , the latest version of react, CDN, you name it! agilemanifesto.org server-side rendering Shouldn’t a website from 2023 be significantly faster than its 20-year-old counterpart? “Matthias, you can’t compare that! The one page is only static text, whereas the other…” yes, the other what? It’s also only text. No more. No less. It has more interactivity, but interactivity does not , especially if it equal a better User Experience makes your website slow. Take the as a counterexample. In 2012, building the kernel on your computer took 1 to 2 hours on current hardware, whereas in 2023, we are . And on the web? Buildpipelines for many teams take far longer than the Linux kernel. And after that, the websites aren’t even ready - only the code that will be downloaded to your computer to create the website. If the website needs 1 second to be rendered by your framework, and you have 4000 visitors, another computing hour is added only to display a website. Linux kernel down to 4 minutes Note: Obviously there were some improvements; the internet got faster, as did browsers. The Agile Manifesto is likely to load faster today on your computer than it did in 2001. This is, however, not thanks to new technologies in web development, only coincidental infrastructural bycatch. Now that was something that became obvious to the grand framework creators, too. Or why do you think they try to push you to server-side rendering? - because it’s simply not feasible to do all of this in the browser. But let’s go back to the 2010s when all that ran its course. We were all terribly scarred by progressive enhancement and looked at the of the (from 10 years before) to learn that we cannot separate presentation from content. Combine that with “a lot of applications need a lot of interaction, thus javascript, so let’s do all there”, and you’re almost at SPA. Oh, the promises. The simplicity of the idea that wisdom ancients view = component(state)(props) A is a pure function with some properties and state… that was simply too alluring. THAT’s developer experience; it makes things so much more manageable! Thus, everybody started to do everything using that paradigm. view Well, developer experience is essential, but it should never come at the expense of user experience. Should you put developer experience above user experience if this makes your website slower? And most of your web applications are still that: websites. And even for your , many parts of your website are still that: Text. Because most of us are not building a new Google spreadsheet, Figma or Miro. And even there, plenty of text does not have to be put through yet another render loop. oh so dynamic web application But the major frameworks are not built to allow other things next to them. So the header is in the application as well. And the footer. And the navigation. And especially the routing. Why do we have to pull so many things into the javascript application, and thus onto the client side, which any cheap web server gives us for free? While adding a lot of complexity and even more scripts? Yes, there are libraries for all those things. But they don’t come for free. They add to the weight of your website and can’t possibly cover all use cases of your browser, , only far more complicated than with a regular web application. so you’re back on the server to handle 404s There’s another issue, which was highlighted by quite early - that your architecture does not get better with single-page applications, but actually worse. Because having the business logic on the server rather than on the client enables your application to allow immediate changes across all clients, not just your SPA. And one of the many things you might end up with is that you’re doing validation at least twice. Stefan Tilkov “But Matthias, Server Side Rendering is here to save us!” - Server side rendering makes things worse, people! Yes, it brings back great stuff like caching and even 404s. But at multiple costs. Let’s check what it actually does - In a server-side rendered single-page application, once the initial HTML and JavaScript code is loaded, subsequent interactions and content updates are typically handled by making requests to an API and dynamically updating the DOM using client-side JavaScript. Also, after the initial loading of the HTML page, the engines that are linking the server and client are usually trying to recreate their representation of the document, which is maybe fast but significantly harder than doing nothing, and then figuring out in what places updates have taken place to then trigger follow up updates. Giving the client that much work just to open a page that was mostly simple enough to be a static HTML page is almost as bad as secretly installing Bitcoin miners on your visitor’s computers. You are wasting their CPU time with nothing. And what’s worse is that you basically achieve something very similar to classic MVC pages, only far more complicated and a nightmare to debug. Where would you even start when you figure there’s an issue in the performance of your website? The other part is the simple fact that many of those frameworks lock you in. Once you’re using React, there’s little chance to escape or ask it nicely to play well with another framework. Yes, you can . It’s almost as easy as convincing a cat to take a bath. And in case you wonder, no, that idea doesn’t scale to your big monolithic ball of mud that you created, and that can be certified as export react components as web components unentangleable. Once you enter their promise, you will be forced to rewrite everything in their framework, or you’ll end up with a very fragmented technology landscape with many things that cannot be shared easily. As a technology manager, on the other hand, it can be challenging to avoid big frameworks in your ecosystem, as they offer many pre-build solutions that will make development much faster initially. As your product becomes more complex and complicated, however, your team will be stuck firefighting performance problems, weird non-reproducible rendering bugs, and sophisticated ways of having reliable and predictable integration tests for the colossal web applications that we are creating today. Yes, those problems will hit you. No matter how capable you or your peers are, given the complexity of the frameworks for single-page applications, and their SSR friends, you can’t understand all their implications. And thus, you will make minor errors in highly specialized cases that only the framework creators could have told you to avoid. And as all those little things pile up to ever slower applications, left behind are Product Owners that are disillusioned by their teams and customers that wait for a second after clicking an entry in the top-level navigation. Don’t get me wrong - I have been there too. I have used many big frameworks, from the Reacts and Angulars to the Backbones and Meteors. And they will always have a special place in my heart, right next to . But the promises of faster websites and ever-better user experiences were a lie, just like the cake. Adobe Flash Such a long rant. So, what do I propose? I can tell you what I use for my as a start. The blog is built with , a static site generator. It pretty much does what site generators have done for centuries - it takes content, in Hugo’s case, markdown files, and creates static HTML. That static HTML you can then put on a server or just directly into a CDN. private website hugo But indeed, only some things on the page are static. But javascript is used economically. Let’s take code snippets like this one: Those are web components that are used where they are needed. But they are embedded in between the static HTML, and their performance does not impact the rest of the page.
<highlight-code location="snippets/hello-world" show="preview,html">
 Loading codebench...
</highlight-code>
I don’t need to use javascript or sophisticated libraries like framer-motion<a href="#fn:12" class="footnote-ref" role="doc-noteref">12</a> for things like animation, but all of that is done by CSS, as I had written in the previous blog post on my hidden relaunch<a href="#fn:13" class="footnote-ref" role="doc-noteref">13</a>. Those are web components that are used where they are needed. But they are embedded in between the static HTML, and their performance does not impact the rest of the page. I don’t need to use javascript or sophisticated libraries like framer-motion for things like animation, but all of that is done by CSS, as I had written in the previous blog post on . my hidden relaunch On top of that, it is essential to ensure that the correct metrics are visualized in order to gain meaningful insights. Unfortunately, many organizations overlook the importance of UX, instead focusing on developer experience and shipping speed or the first result on a lighthouse check which has a more tangible return on investment. So don’t just create dashboards that say “First Contentful Paint: 0.8 s” or “Performance: 100/100”. Create a visualization that you can trace back to your business KPIs, like “98% of bounces have slow Time to First Meaningful Paint”, “72% of non-recurring visitors encountered prolonged execution of JavaScript code” or 17% of visitors to the signup flow have performance that is below converting visitors average". In modern , plenty of great tools can help you build fast and efficient websites without overloading them with JavaScript. Some of these tools, like Svelte and Lit, allow you to use JavaScript only as much as you need while still providing powerful features like reactive data binding and templating. web development Other tools, like Hugo and Eleventy, offer lightweight and flexible static site generators to help you create websites with minimal overhead. By choosing the right tool for the job, you can create both performant and easy-to-maintain websites without sacrificing functionality or design. And if you miss functional components, hey, . I even wrote a library for you Let’s return to the web’s roots and focus on simplicity, reusability, and efficiency, and create a more inclusive and sustainable web for everyone. So that one day, we can come back to having super fast, static websites that even work on 2-year-old mobile phones, pipelines that are building as quickly as the Linux kernel, and all we have to do is to agree to write a little less javascript. Also published here.

Why You Should Ditch JavaScript

No matter how well-architectured the app you built is, if it brings no value to users, chances are, no one will use it. In simple terms, are brief, informal descriptions of a software feature told from the perspective of the users. These answer the and of a single task/functionality in an application. user stories "who," "what," "why" User Story Format As a(n) <user type>, I want to <function> so I can <benefit> Example As a , I want to , so I can . customer view the list of menu items easily choose what food to order The answers the "who," the refers to the "what," and finally, the explains the "why" in a user story. user type function benefit What Makes a Great User Story? Now that you know the typical format for a user story, the next question that comes to mind is . "What makes a great user story?" Your backlog should not be filled with stories that actually do not provide user value. If you do, you could waste a lot of time and effort planning for and working on tasks that don’t add much, if any, business value to your project. Image by from Andre Simones one80agiletraining INVEST Fortunately, coined the term "INVEST" which serves as a reminder of what characteristics of a high-quality user story. INVEST stands for: Bill Wake : User stories should not be dependent on one another. Independent : Should leave space for discussion. Negotiable : Must deliver value to the stakeholders. Valuable : You should be able to estimate the size and scope of a user story. Estimable : The user story should be small enough to easily plan and prioritize it. Small : You should be able to test the results of development. Testable Ideally, your user stories should have all of these characteristics, because they enable you to easily determine how each task fits into your project timeline. By following INVEST, it is much easier to decide which items you must fulfill first, and which ones can wait until later. Examples of Bad User Stories Image by from Roman Pichler romanpichler Here are examples of bad user stories, and why they don't work: As a customer ordering fast food online, I want to find previous food order lists so that I can see all the orders that I have. The benefit/value is absent from this user story, because is just a re-statement of . Problem: so that I can see all the orders that I have find previous food order lists As a QA tester, I want to have access to test plans so that when the product is finished, I know how to test it. Users do not really care about test plans, they just want quality products. Problem: As a Jam’s dining customer, I want various food item categories displayed in different colors: red for meats, magenta for grains, and olive green for vegetables and fruits—so that I can easily group my food items by food type. The user story is way too technically specific and robotic. This not only fails to represent a user but also limits the creativity of the developers. Problem: Examples of Great User Stories Image from justinmind.com In contrast to the previous bad examples, here are the user stories that work well: As a customer ordering fast food online, I want to find my saved food order lists so that I can reuse them for future orders, allowing me to order faster and more accurately. As a Jam’s dining customer, I want items to have a custom item code so that I can quickly find an item on a screen. As a logged in user, I would like a login timeout and log off after a certain amount of time so that I can have some protection against unauthorized use when my computer is left unattended These user stories work well because they have the characteristics of INVEST: Their functionality is not dependent on other stories. They leave room for different implementation options. They add user value to the project. Their scope and size can definitely be estimated by developers. They are small enough to be planned around and/or reprioritized against other stories. They can be tested. Completing a User Story Now that you know how to make great user stories, you'd probably like to know when they are finished. A user story is completed when it meets its and its (DoD). But what do these terms mean? Acceptance Criteria Definition of Done Image from agilemania Acceptance Criteria The Acceptance Criteria of a user story consist of to ensure that the software is working as intended. Like user stories, acceptance criteria should be written from the perspective of a user. the set of test cases that must be fulfilled They should be clear, concise, and easily utilized by the development team. Acceptance criteria should not be concerned about implementation, but only about which features should be present and included. Each user story will have different Acceptance Criteria based on its requirements. Definition of Done (DoD) The Definition of Done (DoD) is a for the team to call it complete. list of requirements that a user story or Increment must adhere to The DoD serves as a checklist that guides various pre-implementation activities such as discussion, estimation, and design. By ensuring that the DoD is followed, the team can minimize reworking on user stories. Its difference from Acceptance Criteria is that whereas . DoD is common for all the user stories Acceptance Criteria are applicable to only a specific user story User Stories in Agile/Scrum Environments Image by from Notion Nate Martins In Agile/Scrum environments, a team would utilize user stories as part of their Product Backlog. Each story represents a single unit of functionality in a project, and a backlog contains multiple user stories. Many teams nowadays use issue trackers or tickets for listing user stories, while others still use sticky notes. As PBIs become higher-ordered in the Product Backlog, they tend to be broken down into user stories with more specific tasks listed. Unlike a Product Backlog Item (PBI), a user story depicts more than just a specific requirement, change, or bug fix. Its focus is on the end-user and their experience. A user story is an increment that provides value to the overall product. 3Cs of User Stories An Agile user story has three primary components, each beginning with the letter "C" hence the "3Cs": Card Conversation Confirmation Card The "Card" refers to the of the user story and serves as an invitation to conversation. written text Typically, user stories would be written on index cards, hence the "Card" aspect. One benefit of this is to keep a user story concise but still provide enough information. It also allows a team to discover more about the user's needs through conversation. The most common format of the user story "Card" is: As a(n) <user type>, I want to <function> so I can <benefit> User stories do not necessarily have to follow this format, but it helps keep those three important things to mind. Conversation The "Conversation" is a , usually in-person, facilitated by the Product Owner. This interaction involves all stakeholders and the team. It encourages continuous, incremental collaboration among the Agile team members by allowing them to have a shared understanding of a problem. collaborative interaction The team will make adjustments to the "Card" based on the information gained from having the "Conversation." While these conversations are typically verbal, automated tests and documentation support them. Confirmation Finally, the "Confirmation" in a user story determines whether it's completed or not. It refers to the . Acceptance Criteria which declare the story's requirements The user story is only finished once the acceptance tests pass and the Acceptance Criteria are met. Typically, the Product Owner will have to verify the completion of the user story before it is considered "done." Pros and Cons of User Stories Image from heavencpa Advantages of User Stories: Helps ensure that a functionality brings user value. Follows Agile/Scrum core principles. Makes it easier to organize software functionality, as it leaves out implementation details. Allows team members of different expertise and backgrounds to plan an application more easily. Encourages conversations rather than simply handing out document details. Simple to prioritize and reorder, especially for product backlog items. Easily understood by both clients and developers. Disadvantages of User Stories: Does not explain the "how?" Does not involve non-functional requirements (e.g. fault tolerance, performance, usability, modifiability) User stories are not substitutes to business requirements. The lack of implementation details means that the processes could vary a lot from team to team. Can be misunderstood and misused. Can lose its original essence/purpose (especially in companies and teams that are "Agile" only for compliance purposes). Frequently Asked Questions (FAQ) Who writes user stories? In an Agile/Scrum environment, the Product Owner is responsible for the backlog of all user stories. Anyone can write user stories. However, anyone in the entire team can make them. Solo developers can also utilize user stories to help guide them when building a project. When should you write user stories? Typically, a team will hold a meeting at the start of the project to create user stories to identify initial project requirements. User stories can be written anytime. It is impossible to identify all of them at the beginning, so the team will create user stories over the course of the project timeline as they discover more user requirements. When is a user story completed or finished? A user story is completed when it meets its Acceptance Criteria and its Definition of Done (DoD). Do user stories replace a requirements document? A user story focuses on the experience and needs of users, while a requirements document goes into a lot of detail about features necessary for a project. They don't, as they serve different purposes. User stories focus on the , , and . On the other hand, requirements documents contain the and . who what why what how What are the differences between user stories and Product Backlog Items? At first glance, they seem similar, but there is a key difference: User stories place an emphasis on the end-users and their experiences. On the other hand, a Product Backlog Item merely represents a specific change, requirement, or bug fix without being concerned much about the . who Are user stories like pseudocode? They are used differently. Pseudocode is mainly concerned about implementation details and how a developer would build a solution, and user stories completely leave out the implementation details in exchange for focusing on the user experience. User stories are mainly concerned about the , , and . On the other hand, pseudocode describe the and . who what why what how Concluding Remarks Writing user stories is not difficult, but it's also easy to get them wrong. You should be fine as long as the user stories you write fulfill the following: Written from the perspective of a user. Identify the user, the feature, and the benefit (or answer the ). "who, what, and why?" Have the characteristics of INVEST. Not too restrictive in terms of implementation. Have Acceptance Criteria and Definition of Done (DoD). However, user stories do not cover implementation details and are not substitutes for a requirements document. User stories are great for identifying user needs and increasing the business value of a product. A user story is the smallest, functional unit in the Agile/Scrum Product Backlog. Most modern software development teams will require you to use it, so it is definitely worth learning. And even as a solo developer, writing down user stories will help you build a project that has user value and prioritize which features you should implement first. Try writing user stories before you build your next project, and see how it helps! Resources/Recommended Reading: User Story Guide by Mike Cohn How To Create a Perfect User Story - Step by Step Guide New to Agile? INVEST in good user stories Definition of Done vs Acceptance Criteria Effective User Stories DISCLAIMER: ***This is a Starter Guide meant for introducing beginners to user stories. *** This guide only expresses my thoughts and opinions (based on my limited knowledge) and is in no way a substitute for actual references. If I ever make a mistake or if you disagree, I would appreciate corrections and discussions in the comments! First published here.

The Art of Writing Agile User Stories

It is a pleasure to announce our next Slogging AMA guest Ian Hamilton. Ian is an accessibility specialist within the games industry. He has worked with countless game developers, and hardware manufactures to improve the accessibility of their games. In this AMA, Ian talks about his role in the gaming industry, what games he has worked on and how he sees the future of accessibility in gaming. This thread by Jack Boreham, Ian Hamilton, Amy Shah, Mónica Freitas, Blake Cram and Limarc Ambalina occurred in slogging's official #gaming channel, and has been edited for readability. Slogging Jack Boreham Oct 21, 2021, 8:57 AM Hey @channel, please join me in welcoming our next AMA guest, an accessibility specialist in the gaming industry. Ian has worked on many video game projects, working with developers and hardware manufacturers to make their hardware and games more accessible for gamers with disabilities. Please feel free to ask Ian anything about: His role in the gaming industry How he works with game developers and hardware manufacturers to improve accessibility. What games he has worked on (well, the ones he can talk about) and his experiences. How he views accessibility in gaming and what the industry can do in the future to improve it. Questions about gaming in general and other burning questions. Jack Boreham Oct 21, 2021, 9:04 AM Hi, thank you for joining us today; it's a pleasure to have you. To start, can you explain a bit about yourself and your role in the gaming industry. Amy Shah Oct 21, 2021, 9:17 AM I would love to know more about your views on accessibility in gaming. Ian Hamilton Oct 21, 2021, 9:22 AM Jack Boreham I'm an accessibility specialist, which means specialising in how to avoid unnecessary barriers that get between disabled gamers and the kind of experiences that developers want their players to have. I've been working in this field for about 16 years, initially alongside design & UX. Now it's all I do. Some of my time is spent on advocacy, so things like speaking, teaching, writing, running a conference. And the rest of my time is on consulting, studios bringing me in to help if they either need some expertise on the topic or have expertise but not enough resources. The things I'm brought in to consult on are pretty varied. I do everything from hands-on design work to audits of builds, production of guidelines, guidance on strategy, recruitment and objectives for user research - it's never dull :) Ian Hamilton Oct 21, 2021, 9:22 AM Amy Shah, what would you like to know? Amy Shah Oct 21, 2021, 9:49 AM What has been your efforts in the area of accessibility? I recently spoke with a blind developer who helped me understand the problems he was facing because of his disability.  He is an extremely resilient, brave person, and this interview shows some of the struggles he was facing. https://hackernoon.com/accessibility-in-the-workplace-companies-dont-give-me-a-fair-shot-says-a-blind-developer Amy Shah Oct 21, 2021, 9:52 AM I found that people, like myself, really are not aware of the advances in technology that make it possible for people with disabilities to do more things. I would like to learn more about what the gaming industry can do to improve accessibility. Jack Boreham Oct 21, 2021, 10:07 AM That must be incredibly rewarding and interesting. It also must be gratifying with the variation of work. Can you give an example of how you've helped a game company make a particular video game more accessible? You also mentioned hands-on design work; what kind of projects? 😄 Ian Hamilton Oct 21, 2021, 10:27 AM They're mostly under super strict NDA, but I can talk about a couple. Minecraft was hands-on design work that was designing wireframes (ie.. rough digital sketches that represent functionality rather than look and feel) of how to implement a subtitling system Destiny 2 was more ongoing, that involved a series of reviews of documents and wireframes (their wireframes) of an advanced and complex. Button remapping system. There's a talk about that here - Ian Hamilton Oct 21, 2021, 10:31 AM A few examples  of work that can't be named Game 1 - ongoing support throughout the whole of development, answering questions and reviewing builds as we went along Game 2 - sourcing disabled gamers to take part in a workshop, a whole day session for developers to get to know their audience and how disability fits in with gaming and their lives in general Game 3 - feeding back on their strategy documents and internally producing accessibility guidelines. I hope that gives a little bit of a flavour of the different kinds of things involved. Amy Shah Oct 21, 2021, 10:51 AM Thanks so much. Another question. How do you build teams and increase teamwork when building a game? Ian Hamilton Oct 21, 2021, 10:54 AM A big chunk of games is built by individuals or a couple of friends. Larger games, like Destiny, can be built by huge teams of several hundred people, divided up according to what kind of discipline they are (e.g. artist, designer, programmer) and what part of the game they're working on. Some are bigger still. A game like Assassins Creed can be made by a dozen or more studios all over the world. 👍 1 Ian Hamilton Oct 21, 2021, 11:01 AM Fostering teamwork is a bit outside of my wheelhouse. But game development is a very iterative process, experimenting, seeing the results, going back to designing again based on what you've learned, repeat.  So it's a natural fit for agile development ( ), that's how most game development is done, with variations on scrum (see the 1-minute video on this page: ) specifically. And that is in itself a way of working that is based entirely on collaboration and communication. https://agilemanifesto.org/ https://resources.scrumalliance.org/Article/quick-guide-things-scrum Jack Boreham Oct 21, 2021, 1:19 PM That's very interesting and does. Thank you for that summary. Destiny 2 and Minecraft are two very different games. Was a particular game easier to work on, or does it depend on what needs to be done? Are specific genres easier at being made more accessible? Mónica Freitas Oct 21, 2021, 2:53 PM Hi, thank you for joining us! Have you ever worked with accessibility in educational games? I find that could open a world of opportunities and represent an extra tool and help for students with disabilities. Ian Hamilton Oct 21, 2021, 3:17 PM Mónica Freitas I have! It can be indeed. But there's a key thing to bear in mind, which is that no game can be fully accessible to everyone because to meet the definition of "game" (instead of something like a toy or a story), it must have an element of challenge, some state of opposition between the player and the rules, standing in the way of them meeting their goal. And any challenge will be exclusionary to someone somewhere. So while it's important to make educational games as accessible as they can be, it's also important to not rely solely on them, for it to still be possible to reach the same educational goals by other means too. 🔥 1 Ian Hamilton Oct 21, 2021, 3:18 PM That's something that separates accessibility in games from accessibility in other industries, that notion of necessary and intentional exclusion. IT means that instead of accessibility in games being a standardised checklist of things to tick off to meet a generally reasonable level of accommodation, it's rather an optimisation process. Working out for each game which of the many barriers it presents are a necessary part of what gives the experience any value, and which are not, and working to avoid the latter. Ian Hamilton Oct 21, 2021, 3:19 PM It is nice because it means it's always a design exercise of figuring out how to reach as wide a range of your target audience as possible. It can't be just a box-ticking exercise. 🔥 1 Blake Cram Oct 21, 2021, 5:07 PM Thanks for being here! Really appreciate the work you're doing! I think it's a really interesting problem to navigate the fact that games require some sort of challenge or barrier for entry,  yet we want as many people to enjoy games as possible. Are there any challenges in accessibility currently that you or your colleagues are working on? Such as finding ways to make games available to folks with particular disabilities or further improving the quality of accessibility where it's lacking? Ian Hamilton Oct 21, 2021, 7:53 PM Blake Cram, the challenges have shifted a bit. A few years ago, it was still about awareness, trying to educate and motivate people about the need. Now it's more about the how. Trying to get it to start earlier in development, integrated into workflows and processes, that kind of stuff. There is still some educating and awareness needed but, now it's less about "this is what accessibility is and why it matters" and more about dispelling misconceptions around things like return on investment. Does that kind of answer it? Limarc Ambalina Oct 21, 2021, 9:27 PM I hope you're well, and thanks for joining us here on Slogging. I heard you worked on The Last of Us. Is everything you did there under NDA as well, or can you talk about it a bit? I'm a die-hard LOU fan so just talking to anyone who worked on that project is an honour. I'd love to hear about what you did to make the game more accessible. Limarc Ambalina Oct 22, 2021, 1:24 AM Secondly, I’m hardcore into VR these days and the experiences it provides to people with disabilities. People in wheelchairs can run around in Skyrim or fly a spaceship, etc. Have you been doing any work or consulting in the VR space? Mónica Freitas Oct 22, 2021, 1:56 PM It makes complete sense! Thank you so much! ❤ 1 Ian Hamilton Oct 22, 2021, 1:58 PM Limarc Ambalina: Yeah, I'm allowed to say that I worked on it, but am not allowed to give any details, unfortunately 😆. Limarc Ambalina I used to do a lot of VR consulting, but not any more. It was too hard to have any professional association with VR because I felt too bitter towards the technology from the permanent harm it caused me. I don't think it is safe to be on the market. But here is some of my old VR work - http://ian-hamilton.com/vr-accessibility/ Limarc Ambalina Oct 22, 2021, 3:58 PM Thanks, and that's super interesting, but I'm sorry to hear that! Care to tell us a little bit about what you feel is dangerous about VR? As someone who uses the Quest 2 every day, I'd love to hear if I'm unknowingly putting myself in harm's way. Ian Hamilton Oct 22, 2021, 9:18 PM Limarc Ambalina, there's a bit about my situation in that article. It's simulation sickness, particularly what can happen if you try to just push on through. That's what I did as I was doing a limited time audit and was in a state for days. As a result, if I'd have had to drive a car or operate heavy machinery or something, the impact could have been severe. And I never fully recovered, meaning I now have bad car sickness, can't use VR at all, can't watch others playing games which in turn clocks off Twitch which has an impact on being able to work. The killer for me has been impacting childcare. I can't push my daughter in a swing or look after her while in the car. It isn't very common, but I know a few other people in the same situation. So it's endlessly frustrating to see people talk about "VR legs" - that's a dangerous concept! 😮 1 Ian Hamilton Oct 23, 2021, 8:41 AM So the advice I'd give (and would like to see at the start, like epilepsy warnings) is that if you start to feel a bit out of sorts, not even as far as nausea but just things like clammy forehead, feeling hot or cold, a bit disoriented, stop immediately and don't play again until the next day. Don't try to push on through. Jack Boreham Oct 23, 2021, 8:59 AM Well, that's a wrap for this AMA; thank you for joining us. It's been a pleasure to have you. We hope you have enjoyed it. Ian Hamilton Oct 23, 2021, 10:21 AM Yes, thank you for having me! If you want to chat outside this AMA, you can reach me on Twitter at @ianhamilton_, and if you want to learn more about the topic, there are a ton of great resources and articles here - https://igda-gasig.org/how/for-developers-researchers/ 💚 1 ❤ 1 Limarc Ambalina Oct 24, 2021, 8:53 AM Thanks for the personal story. I'm sorry to hear that. I've never heard of this issue before. I had heard the articles on VR legs and have tried the "go 2-3 minutes at a time approach" when I first got motion sickness. And for me, it did work, and I do now have VR legs. But it's scary that it could have impacted my life in that way Ian Hamilton Oct 24, 2021, 9:20 AM Limarc Ambalina, yeah, the issue with that advice being given to people is that for some people, each repeated experience of simulation sickness makes them more prone to it in future rather than less prone. This article is part of The hosted by HackerNoon in partnership with . Gaming Metaverse Writing Contest The Sandbox Submit your story today for your chance to win up to $2000. #gaming-metaverse

Making Games More Accessible With Accessibility Specialist Ian Hamilton 

Top 50 App Development Companies: 50 Brands to Look Out For

Hey there, I read a good bit this last year and want to share the ones that made my year 10x better. I work in technology but have interest in health, psychology, behavioral economics and more. Stick around the site and check back in for more book writeups. For now though, let’s dive in to the ones I read last year that made my year 10x better. Creative Selection by Ken Kocienda Yes… obligatory cliché Steve Jobs book. I know — the FIRST one too. But give me a chance, this is actually written by the engineer who worked on the iPad keyboard. He gives great detail about interactions with the product team at Apple, and how they operate. Apple sold 320 million iPads since the product debuted in 2010, so Ken’s work did make quite an impact. That’s more people than there are alive in the United States. If you work in product this book is a must read. View the way a visionary ran his company. Order here. Hacking Growth by Sean Ellis This is one of the many books that I was late on. The book is filled with actionable advice, along with charts to support real results from methods discussed. My copy is covered with notes, and ideas sparked from the insights provided by Sean. I am a big fan of and from and they referenced this one a good bit. I decided to pick it up and couldn’t put it back down — if you have any interest in growth then this is an essential. Andrew Chen Casey Winters Reforge Order here. The War of Art by Steven Pressfield I recently became obsessed with content creation. Steven does a great job breaking down the walls you need to destroy to be a great creator. Order here. Those people fighting are your thoughts. Blitzscaling by Reid Hoffman I have not finished this one but am throwing it in here anyways. Reid is a total badass when it comes to story telling. I listen to his podcast “Masters Of Scale” religiously. If you love the idea of growing companies at bullet train speed then check it out. Order here. If you want to `send it`, you may as well read how others have `sent it` :) Rework by Jason Fried and David The guys at get a lot of flack for their controversial approach to work. It is so opposite to what everyone in the Valley has been preaching, and I love it. This book goes deep, taking a totally different mentality towards work, and the way to get it done. These guys have gone on to write many more, including Remote which I read. Short after reading this, my VP of Engineering, and I decided to flip our processes on their head. Now we follow suit on many of the methodologies taught in this book. We agile’d agile. Basecamp Kayle Order here. Remote by Jason Friend and David. Work doesn’t have to be done in an office. Managers no longer need to be chair counters, now they can be doers. Remote talks all about, you guessed it, working remote. Basecamp is comprised of a team of people located all across the United States. Jason and David do a great job explaining their process and how they continue to run a profitable company while having a majority of employees working remote. Order here. Body by Science by Doug McGuff Md I read a lot about fitness and health — this is a great book for understanding the basics of different exercises. Sure you can look up different exercises online, or purchase a plan.. but that wasn’t enough for me. I was curious as to how all these muscle groups work with one another. If you’re a health nut, pick this one up. Order here. The Power of When by Michael Breus, PhD If you’re in to understanding your body, and when you should do certain tasks than this is a good one. We all kind of know that some people are night owls, some people are morning people. This guy breaks it down to a science. If you are this type of person, do these tasks at this time — very specific, actionable advice. The book talks about chronotypes — which are the behavioral manifestation of underlying circadian rhythms, of myriad physical processes. He talks a lot about sleep. Check it out. Order here. Inspired by Marty Cagan This is a must read for any PM out there. Talks about different levels of product growth, and was the best product book I read all year. It starts out with lessons from top tech companies, get s into talking about right people, then dives in to product breakdowns. Order here by Elad Gil High Growth Handbook Looking for a lot of different topics about startups? The role of a CEO, Managing the Board, recruiting, hiring, managing, building an exec team, marketing & PR… You get the idea. Lots and lots of information on scaling startups from 10 to 10,000. Overall a great book to skip around to check things out — not a cover to cover book. Order here. by Al Ries & Jack Trout 10 Immutable Laws of Marketing If you have any sort of interest in marketing than this is a must. It does a great job of breaking down the different “laws” of marketing using companies we are all familiar with, ie. Apple. One that is particularly interesting is The Law of Perception. Marketing is not a battle of products, it’s a battle of perceptions. I got this recommendation from listening to Seeking Wisdom — a dope podcast by and . Dave Gerhardt David Cancel Order here. by David Asprey Bulletproof I have been on the bulletproof coffee train since reading this and haven’t turned back. David did an excellent job keeping nutritional information interesting. He gets a bit in to biohacking, aka taking supplements, doing certain things in your day to day to increase brain behavior. This was the first book that has sent me down the rabbit hole that is bio hacking. If you want to live longer read his book. Order here. Bulletproof coffee is tasty and gets the day going. by John Joseph Meat is for Pussies: A How-to Guide for Dudes Who Want to Get Fit, Kick Ass, and Take Names As I peer over at my bookcase, selecting recommendations from the books I read this year I wonder how this one came up. I must have read some blog article about how terrible meat is for you. Anyways the name itself kicked the tempo off for the book. It is rare that I find a book that I cannot put down. This is by far the best vegan … only vegan book I have ever read. “Walk past the morgue and head straight to the vegetables.” Such imagery. Order here.. by Brad Frost Atomic Design If you are in product you must read this. I don’t care if you’re a designer, engineer, or product manager. Brad does an excellent job of breaking down his philosophy behind UI design. The result is cleaner, more consistent products which lead to happier users. Everyone wants happier users. Order here. by Scott Jehl and Josh Clark Designing for Touch & Responsible Responsive Design, These books absolutely nail how to design for touch, as well as responsible responsive design. If you are a UX researcher, UI designer, or product designer you should highly consider reading these. They break things down, and give you the chops you need to work with devs on mobile and responsive projects. Order here. Thanks for reading — follow along with my thoughts on twitter.

Download these Books and Crush Life

One of the most recent trends in software development is combining Agile methodologies to get a unique, hybrid approach that helps an organization to achieve better results. We at have our very own combination of Agile and Scrumban. Let’s talk about how to build such a tool, and what to expect as a result. 1Ci Agile as a foundation The principles of this methodology can be found at agilemanifesto.org. Commonly, Agile introduces 4 values and 12 principles. However, different Agile approaches can go back and forth from points in the Manifesto, and this is allowed by the document. The “Agile Manifesto” describes common goals for businesses, including embracing individual’s values and interactions over processes and tools (software > documentation, value for customer > code, etc.) Agile gave birth to a bunch of methodologies for software development. Scrum and Kanban are two of the most popular. Scrum for a clear process Scrum is a framework, consisting of three roles, five events, and three artifacts. The roles are Product Owner, Scrum Master and Development Team, the events include Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective, while the artifacts are Product Backlog, Sprint Backlog and Product Increment. Regarding software development, the process is constantly repeated in a certain period of time called Sprint. Sprint may be something between one and four weeks. More freedom with Kanban Kanban, in turn, is a methodology built around five properties and four principles. It involves using cards containing details about a request. These cards are organized on a board in such a way as to define the development process clearly. In the basic situation, you can have a board with cards divided into three columns: To Do, In Progress, Done. Once it is agreed that the task on the card has been processed and now meets the requirements for the next column, it can be moved there. In such an order every task is handled. Therefore, Kanban is more about incremental, evolutionary change. The pros and cons of Scrum and Kanban Both Scrum and Kanban are methodologies that focus on lean and agile software development processes. They involve frequent releases, encourage the introduction of self-organized teams, continuous improvement and the setting of priorities based on the value businesses can get from a certain update. Scrum is a strict methodology: it has thoroughly described roles, artifacts and timeframes for delivery (sprints). Kanban gives more freedom than Scrum; it only requires the visualization of the workflow (using board and cards), limiting work in process, constant measurement and improving the flow. However, both of these methodologies have their complexities. For example, when implementing Scrum, it might be hard for team members to meet the deadlines of time-boxed sprints. Some developers even believe that the requirement for releasing new features at every sprint also slows the overall development process down and creates an overhead and unnecessary pressure. Management might want to see significant results in absolutely unrealistic time frames. Kanban is a less-structured methodology, which may be right, but also introduces some problems. Too much freedom is not always a good thing as some teams might become less productive in such an environment. Also, there are critics of Kanban as a methodology that believe it does not suit such a creative process as software development. It was first introduced at Toyota’s manufacturing line, so it is very linear, which is suitable for repetitive processes and noncomplex systems with multiples parameters. Sometimes it is hard for a newly-organized team to use Kanban to develop new features. To get rid of most of the problems of Agile software development methodologies and benefit from their flexibility and freedom, it is a good idea to use a hybrid approach. You can take only the elements that suit your team and business. Here is how it may look, based on our experience. Combining Agile and Scrumban In 2009, engineer and software developer Corey Ladas was the first to come up with a description of a hybrid Scrum/Kanban model. He introduced the term “Scrumban.” Ladas suggested starting with Scrum, working on process optimization and quality so that such time-boxed sprints are no longer necessary, and then the freedom of Kanban may be used in full. Here at we use our own blend of Agile, Kanban, and Scrum. Here is how it works: 1Ci We have several channels for accumulating information about tasks and requests for new features. After the development team gets an understanding of what users and other stakeholders expect to see in the product, we can move to requirement formalization. After the task is correctly described, there is voting on whether it should be implemented in the next sprint or not. The product owner reviews the arguments of all stakeholders and makes the final decision. The next step is designing a user story tailored to a specific task, including its priority. When we have all of this information in place, the programming magic starts. Finally, we have a new feature designed within a given sprint time. Conclusion: what do you get? A hybrid approach to Agile and Lean software development has three major advantages: . You are building new features that are demanded by the market (customers, partners, etc.) rather than working on something you expect will make someone happy. Market-driven development . A traditional waterfall approach assumes long planning, delivering big updates and analyzing the results. In today’s fast-paced business environment, this does not work. Agile development allows you to be flexible, to react to new events and requests from customers quickly, and see results and make amendments. More flexibility . By dividing the overall, big development process into small sprints, you are constantly delivering new software. This is good both for the product, as it becomes functional, and users, as they get the features they need, but also to the programming team as well. Programmers like writing code that works in production. Seeing the results of your work, made in a week or a month, up and running is one of the best rewards for engineers. Continuous delivery Agile implementation is an endless process with no final point. Keep working and optimizing, and you will get better results and higher productivity. Good luck!

Agile + Scrumban For Better Productivity: How to Create a Hybrid Software Development Process

We broadly covered in our whitepaper. If you don’t know the basics, feel free to check the paper first. Here, we make a short recap of the main methods used in Agile. Agile development approaches and methods Sources: Pulse of the Profession 2017 — http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en Gartner glossary: Project Managment — https://blogs.gartner.com/it-glossary/project-management/ Managing the Development of Large Software Systems — http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf 11th Annual State of Agile Report — https://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agile-report-2 The new product development game — https://hbr.org/1986/01/the-new-new-product-development-game Iterative and Incremental Development: A Brief History — https://www.cs.umd.edu/~basili/publications/journals/J90.pdf Manifesto for Agile Software Development — http://www.agilemanifesto.org/ The Scrum Guide — http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100 Object-oriented Programming, Systems, Languages and Applications — http://www.sigplan.org/Conferences/OOPSLA/ The State of Scrum Report 2017 — https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Files%20and%20PDFs/State%20of%20Scrum/State0fScrum_2016_FINAL.pdf?aliId=261272923 Toyota Production System — http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/ Gartner glossary: Bimodal — https://www.gartner.com/it-glossary/bimodal/ Bimodal IT — http://www1.softwareag.com/corporate/images/SAG_Bimodal_IT_8PG_WP_Aug16-Web_tcm16-143391.pdf Poppendieck — http://www.poppendieck.com/ Lean Software Development: An Agile Toolkit — http://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf Guidelines for Test-driven Development — https://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx Strengthening the Case for Pair-Programming — http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF Programming in Pairs: How to Get Started — https://www.ibm.com/devops/method/content/code/practice_pair_programming Extreme Programming: A Gentle Introduction — http://www.extremeprogramming.org/index.html Originally published at AltexSoft Tech Blog ‘ Agile Project Management Methods’

[Infographic] Agile Project Management Methods

When building a company, you often have to make sacrifices. There is never enough time, money, or talent to get everything done. Sure, you’d like to build your product the right way, but you’ve got to get something built quickly so you can raise money, or get new features out the door so you can land that big client. I get it. There’s no time to plan! We have to move fast! Then one day, you’ve finally got your feet under you. You’ve gained some traction, you’ve got revenue coming in, and you’re growing quickly. You’ve been bootstrapping and hustling and crushing it. You’ve arrived. Now you’re starting to notice something is off. Your engineers used to be able to crank out new features quickly, but they’re now missing deadlines, and they’re having a hard time telling you when things are going to get done. Things are breaking more often in production, and you feel like you’re constantly in fire-fighting mode. The system seems to be slowing down, and your users are complaining about performance and bugs. Your employees seem burned out, maybe you’ve even lost a few people, and your new hires are having a hard time getting up to speed. All those corners you cut to get where you are now are killing your productivity, your morale, and your business. You avoided paying the true cost of software development, and now the debt is due, . You are now bogged down with technical debt. with interest Almost every company I consult with suffers from this problem to some degree. A certain amount of technical debt is excusable, but you need to start paying it down, or your productivity will grind to a halt. Sure, it will add overhead, but as your team gains momentum by clearing the roadblocks, you’ll start seeing improvements in every area of your business. This is unavoidable, so you might as well get started now. Let’s discuss some of the critical areas where you’re likely not paying the true cost of software development, and some important steps you can take to get on the right track. Development Process “We do Scrum, sorta” is a phrase I hear with almost every client I meet. This typically means they use Jira to track tasks, and they time-box their work into sprints. Maybe at the end of the sprint they release to production. That’s about it. Yet they are missing the single most critical aspect of agile development: . The foundation of agile development is based on reflection and continuous improvement. Throw away every other aspect of Scrum, Kanban, or Mob. If you aren’t doing a retrospective after every sprint, you are never going to improve. Yes, it takes time, but if you aren’t investing in your growth, you will never grow. the retrospective An effective retrospective is a process of reflection, communication, brainstorming, and experimentation. We discuss what went well and what didn’t during the last sprint. We communicate our frustrations to each other in a constructive and honest way. We brainstorm ideas for tweaking the process or communication to improve, and we commit to experimenting with a new process during the next sprint. The ideas that fail are discarded, and the ideas that succeed are baked into the process going forward. Credit Scrum.org Requirements Definition There is often a language barrier between product management and engineering. Product managers typically think in terms of user-benefits, while engineers think in terms of technical implementation. PMs think high level, while engineers are down in the weeds. This communication breakdown results in a lot of wasted time and effort to clearly define the goal and how it should be implemented in fine detail. Your PMs should capture the vision of the feature in an effective . They must then account for all the “what if” scenarios of various use cases. I typically follow the user story with a series of if-then statements that account for as many edge cases as possible. You should also include acceptance criteria, ideally in the form of a test case. While you certainly want to leave room for the developers to be creative, there should be no ambiguity about what success looks like. user story Code Reviews After the retrospective, the code review is the second most important ritual in software development. This is not just about walking through code line by line, it’s about explaining the user story, validating that it has real success criteria, demonstrating that it works correctly, and ensuring the code is up to standard. My process for a code review looks like this: Review the feature request and explain the purpose and objectives. Describe the problem to be solved — Review the test cases associated with the feature. Make sure there is a clear definition of “done”. Review success criteria — Explain the architecture and design. Look for adherence to coding standards and best-practices. Ensure the code is clean and well documented. Look for opportunities to improve architecture, modularity, security, and performance. Review the code — Show that the feature works as intended in a test environment. Walk through test cases and prove that the feature is functionally complete. Demonstrate the code — Ensure that some level of test and deployment automation were developed to support the feature. Show that the automated tests are integrated into the CI/CD pipeline. Review test and deployment automation — Paste the notes from your code review in the pull request and the original task as an audit trail that the code review was completed successfully. Capture notes in the pull request and task — Code Management When I engage with new clients, one of the first areas where I look for disorganization is in the code repository. I’ve seen hundreds feature branches that haven’t been removed since inception. I’ve seen commits with no commit message. I’ve seen developers commit directly to master without a code review. I’ve seen developers working against revisions that are out of sync with production. The horror.. The horror! For starters, . Every developer should create a new feature branch for each new story. When a feature is complete, it should be merged into a branch. When a release is pushed to production, a release branch should be created as an artifact of that release. The feature branch should then be deleted after release. use the Git Workflow development Credit Atlassian Don’t commit straight into a main branch. No pull request should be approved without performing a code review first. Use pull requests to merge branches. . Your code history should be readable, just like your code. Create meaningful commit messages, and use descriptive names for branches Architecture Imagine if you were trying to build a house with no blueprint and no foundation. You decided to just start slapping boards together, because you needed to get the house built quickly. This might work if you were building a tree house, but not a skyscraper. The same goes for software. , and use them consistently. Keep them up to date. Don’t reinvent the wheel, use frameworks like , , , , etc. Use frameworks Laravel Express Rails Django . Any interaction between components should be done either via an API or an object interface. Reusable components should be put into a class. Use object-oriented design The database interaction layer is where the most security risk and effort to refactor come from. Create a solid data layer that is holy ground with respect to coding and security standards. Don’t allow any database interaction outside of this layer. Abstract and protect the database. . Adopt a micro-services model if possible. APIs allow systems to easily scale with additional hosts and a load balancer. Use APIs to communicate between major components wherever possible, e.g. MVC/MVVM, Factory, Singleton, Observer, etc. Use design patterns of object-oriented . Use the SOLID Principles design , and generally pay attention to . Limit nested loops and recursion code complexity Data Model Design The data model is the foundation of software. If there is one area to focus on early on, it is creating a clear, logical, scalable data model. Since every piece of code writes to or reads from the same set of data tables, it is incredibly difficult to alter your data model later on. I find that retrofitting a new data model to an existing codebase is the most expensive type of maintenance. For example, do not store numeric or datetime data in varchar fields. Use appropriate data types. This allows you to easily change the underlying data structure later on, without having to change the code. Use views to abstract the data model from the code. This greatly speeds up query performance. Indexes work best on fields that have repeated values. For example, an index on a field containing colors will perform much better than an index on a date-time field, where most values will be unique. Create indexes on tables based on likely query usage. Most data models contain fields that have a pre-defined set of possible values. For example, cars may have a limited number of colors. A reference table contains all the possible values for a dimension, with an ID and any relevant metadata describing each option. Use reference tables for structured reference data. Do not use redundant fields like field1, field2, field3. The link tables should contain foreign keys to both tables, and any metadata that describes the relationship between the two records. For example, the link table that links people to cars might contain the fields years_owned and is_primary_driver. Use link tables whenever there is a many-to-many relationship between two tables. You should avoid performing complex calculations at run time. Pre-cache reports by creating a table containing all the fields necessary to populate the report without any additional joins. Indexes should be created for the main filtering criteria When publishing reports, create reporting tables to greatly boost performance. QA and Test Automation QA does not mean kicking the tires on a new feature. It doesn’t mean going through the main workflow, using only obvious valid inputs. QA is about trying to break the system in a thorough, predetermined, methodical way. First, you should create test cases with a proper template, such as: A numeric value, which will be referenced by the test plan document. It could be the ID of the task in Jira. Test Case ID: A single descriptive sentence, usually prefixed by the component it tests, like Login or Purchase. Title: A short paragraph giving context about the feature you’re testing and how it should behave. Description: Things that must be done to setup the test case, like “Must be logged in as administrator” Preconditions: The detailed steps to execute the test case. They should be written as clearly and concisely as possible, and should be “dummy-proof”, meaning anyone can execute them without any prior knowledge of the system. Test Steps: What you should expect to see if the test passes. Again, it should be clearly written with zero ambiguity. If the expected results aren’t met, the test fails. Expected Results: As you create new test cases, you should capture them in a test plan document. This is typically a spreadsheet that lists all the test cases which should be run with each QA cycle. I use a which I duplicate for every release. As we run through each test case, we set a Pass/Fail value on the sheet, and link to a bug report in the case of a failure. As a part of our deployment process, we make sure QA has delivered a completed test plan prior to release. master template In the test plan, I specify whether a test case is applicable for a smoke test, a full regression test, and/or post-deployment validation. I also say whether the test has been fully automated. I also include a link to a follow-up bug task in case the test fails. Deployment Automation and Server Configuration Manual deployments introduce an incredible amount of risk. If your developers, who are likely under pressure to release on time, forget one step in a long deployment checklist, it can wreak havoc. They’ve got to ensure the correct code branch is deployed, database schema changes are promoted, reference data are deployed, and any new infrastructure changes are deployed consistently across the environment. There is too much room for error. All of your deployments and resource provisioning should be scripted and automated. Use tools like , , , or one of the continuous deployment tools available. Use , , , or to automatically provision and scale your server infrastructure. For test automation, use , , , or the analog for your language of choice. Chef TeamCity Jenkins many other Docker Heroku Kubernetes Vagrant Selenium Mocha + Chai phpUnit Monitoring and Alerting When something does go wrong (and believe me, it will), how will you know? Will you wait for your clients to call and complain? If you get hacked or DDoSed, would you like to know right away, or after your platform is crushed? You should setup robust application monitoring and alerting for your infrastructure resources, URLs and API endpoints, and error logs. For error logs, I am a big fan of the stack. If you’re on AWS, you can set this up as a turn-key service. This stack allows you to post logs in JSON format with tags and values, which you can then search and filter in Kibana. You can create dashboards, reports, and alerts based on log data. No more will you have to ssh into servers and scan huge text files to find out what’s wrong with your system. Elasticsearch / Logstash / Kibana (ELK) For endpoint testing, I use and . You can create simple tests to hit your key URLs and APIs and parse responses. You can then create alerts that will tell you if your system is not responding, or returning errors. Runscope NewRelic Security Security is the great bogeyman of software development. No one can ever be perfectly secure, and investing in security does hinder agility. It’s an inconvenience, but a necessary one. However, I’ve seen companies that completely disregard security, and can only be persuaded to invest in security with a carrot or a stick. Either they have to be HIPAA or PCI DSS compliant to avoid fines, or they can sell enhanced security as a differentiating factor. I approach security as a set of business risks. I create a risk register for my clients that include all the things that could go wrong given their level of security, and the impact it would have on the business in each of these three areas. The business then prioritizes the risk, and we work to plug the holes. I always refer to the guidelines for secure coding standards, and the standards for infrastructure, database, and physical security. Security risks largely fall into three categories: system availability, data loss, or data exposure. OWASP Top 10 PCI DSS Documentation Ahh, documentation, the bane of every coder’s existence, right? We don’t want to create documentation that sits on a shelf, or becomes obsolete as soon as it’s written. We don’t have time to write docs, we need to push more features! When your company grows, and you start hiring new people, how will you train them? How will they discover how the system works? How will they know what will break if they change some logic? If you don’t invest in documentation, you will have to use the time of your other developers to train every new person who joins the team. If you invest in documentation once, you can onboard many new people with the same investment. I’m a champion of agility in all aspects of business, and documentation is no exception. I’m a big fan of wikis like for capturing bare-bones documentation that can be easily updated and referenced. Do anything you can to capture the information. Take screenshots, record videos, screen captures, whatever it takes to get it down so others can refer to it later. Don’t have time to develop sophisticated architecture diagrams? Sketch them on a whiteboard and take a picture with your phone. Confluence Good enough! (Credit Agilemodeling.com) Operational Support Tools All platforms need maintenance. You may have scheduled tasks that fail, data cleanup tasks, and user support tasks that all need to read/write to the database. Any repetitive operational support tasks should be automated with a simple software tool. Most companies, however, avoid the cost of building the tools, but end up spending much more in the long run by pulling developers away from development to support the system. Conclusion Early in a company’s life cycle, you can get away with avoiding a lot of this overhead. You can scrap together an MVP and get to market quickly. You can scale to a certain point before the seams start to tear. Eventually though, you will have to get with the program and start paying the true cost of software development. The longer you wait, the more expensive it will be to retrofit. How much of this do you think applies to you? Come on, you know it, I know it, we both know it. Don’t let this be you: Credit interwebs I Can Guide You Through This Process! I’ve built my practice around helping growing tech companies mature their product development process. It may seem daunting, but trust me, I can help you start making small, iterative, meaningful progress in the right direction. If you think you’re over-burdened with technical debt, and let’s get you on the right path! reach out to me on my website If you’d like to read more of my articles on product development, leadership, and software development process, . You can also find my conference talks and podcasts on my . follow me on Medium media page I Guess This Clapping Thing Is Important, so If You Made It This Far, Please Click Furiously!

You’re Not Paying the True Cost of Software Development, and It’s Killing Your Business

Harold Campbell, Shane Ferley and Brain Leke What’s the current problem? Non-agile delivery methods are costly, slow and often deliver software that requires expensive rework. Additionally, these delivery methods often don’t deliver the expected customer and business value. Bummer. Some common problems that affect organisations that use non-agile delivery methods include: Expensive project deliverables Expensive re-works Delayed Projects Missed market opportunities Being unable to deliver meaningful value to clients Lots of “Accidental” Complexity Ballooning of costs Inherent “Waste” embedded in rigid processes, re-enforced by organisational culture Silo-ed teams Poor collaboration between teams “Code then Fix” approach to delivery Difficult to respond “Quickly” to market changes Long feedback loops between product delivery and expected customer value Phased SDLC Little to no predictability (e.g. quality, schedules, risk, costs, value, etc.) Strong focus on process and tools, over delivering “actual” business and customer value What is Agile? Hmmm. So what’s this thing then? Agile Agile is a group of delivery methods, principles and practices for effectively delivering software that leverages collaboration and customer feedback. There are various Agile Delivery Methods, like: XP Scrum/Kanban/Scrumban SAFe/LeSS/DAD FDD Crystal Adaptive Software Development Lean Software Development At its core however, Agile is about four things really: : Focus on Income and Learning Delivery : Focus on Trust and Team collaboration Collaboration : Focus on Insights, Improvements (and celebrating success) Reflection : Focus on Experimentation and Change (which includes Data-driven decisions and Hypothesis validation) Improvement actual Alistair Cockburn (Co-author of the Agile Manifesto) referred to these four principles as . The Heart of Agile See: http://heartofagile.com/expanding-the-diagram/ Additionally, when using Agile Delivery methods, we use iterative processes to deliver small increments of value at short and regular intervals (AKA sprints, or iterations). These iterations are typically either 2 or 4 weeks long. Steven Thomas: Iterative Incremental See: http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa However, just having short iterations where no business or customer value is being delivered at the end of each iteration really doesn’t help. We need both: An iterative process incremental delivery of value. and Henrik Kniberg: Iterative Incremental Also see: https://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental What do the delivery teams look like? Short answer: It depends on the “flavour” of Agile that you are using. For instance, Kanban is structure agnostic. While Scrum, another popular methodology, has the following structure: 1 x Product Owner 1 x Scrum Master Development Team (the people that produce the actual product): QAs, Analysts, UX, Developers, etc. Going back to that iterative process and sticking with Scrum, their process may look like the figure below. Scrum’s delivery process Why Agile? Staying relevant, innovating and increasing shareholder value are some of key reasons why companies undertake delivery transformation, with Agile. The benefits are similar but more wide-reaching. Additional benefits of adopting Agile Delivery methods include: Happier and more productive employees “Healthier” delivery teams and work environments Fast feedback from customers Early validation of business and market assumptions Increased innovation More predictable product delivery costs Shorter delivery cycles Less risky product delivery More predictable cycles/cadences (e.g. releases, inspect and adapt, etc.) Continuous focus on improvement Agile Delivery Values There are only four values that guide Agile Delivery methods. The four values are: A focus on delivering working software A focus on customer collaboration A focus on individuals and their interactions A focus on responding to change See: http://agilemanifesto.org These four values relate directly to the four principles that are at the Heart of Agile (described above). Scrum, Kanban, XP, SAFe, , (etc.) are all just frameworks/methods that build on these four values. Different methodologies (or the various combinations) will be better suited for different types of teams , or organisations — There is NO ONE TRUE WAY! insert-shiny-new-agile-thing-here Once your delivery methodology is based on the four values above, there is a deliberate focus on delivery, collaboration, reflection and improvement, . and you will become agile What’s required from Executives? A shift in the organization will require a shift in thinking and most likely changes in organizational structures and processes. Executives need to lead the transformation. This is done by: Changing mindset Shifting from Command-and-Control to Mutual Learning Being courageous (by being vulnerable) Adopting the Agile values and principles Focusing on delivering value vs. meeting deadlines and plans Being transparent Learning from “Short” failures Embracing the fact that the adoption of some Agile delivery practices require structural changes within the organization (e.g DevOps). will How do you adopt Agile Methods in your organisation? Again, like with most things Agile, it depends. Adoption can be seen as a two-pronged transformation initiative — it will require changes in cultural principles and delivery practices. Cultural Principles Culture is that intangible thing that resists change within your company. It is thing that embodies the ethos of the organization. As such, it is critical that a systematic, from the inside-out approach, is taken to change cultural norms, assumptions and beliefs. This is where the “radical shift” needs to happen. the To achieve this, there are a few core principles that should be adopted and promoted within the company. Specifically, these include: Servant Leadership Coaching — Process, technical, leadership and behavioral Continuous learning — Promoted at the organization, team and individual-level; and is budgeted for and factored in during planning Frequent reflection — Retrospectives, Sprint/Iteration reviews, etc. Individual feedback — Effective/impact feedback, speed-dating feedback, etc. Estimations as guides not commitments — shift from date-driven planning to value-driven planning. Engineering effort estimates seen only as guides and not “holy” commitments that can’t be changed. This promotes transparency and ensures that any change in facts, assumptions and dependencies, or knowledge and experience (e.g. changes to the team), that will impact delivery are shared as soon as they are known should be Harold Campbell and Brain Leke: All Estimates are lies! Data-driven decisions — PDCA/Build, measure, learn/OODA models Incremental delivery of value — see above Delivery Practices At the other end of the spectrum are delivery practices. These changes refer directly to how we deliver software. These practices typically include: Engineering practices — adopting Test-driven development, Pairing, having a code repository were developers commit code frequently (e.g. daily vs weekly), etc. DevOps — Practices that focus on getting fast build feedback, reporting, automated testing, improving code quality, continuous integration and continuous delivery of software Co-location — As much as possible, having the development team together or being able to collaborate easily Small batches in queues Work-In-Progress limits Self-organising teams Continuous team/self assessments Transparency over Cover-Your-Ass Iterative software development — see above Delivery team provides estimates for engineering effort — The people doing the work make the estimates Empiricism — Data-driven decisions using hypothesis validation (e.g. with Plan-Do-Check-Act/Build-Measure-Learn) Next Steps Pick a method and start. It’s doesn’t really matter if you start with Scrum or Kanban or whichever. Simply start. What is important however, regardless of your organisation’s maturity, is that you have a process that is focused on consistently improving your delivery, collaboration and reflection processes. Special thanks to Shane Ferley and Brain Leke for their contributions and feedback in creating this piece!

Agile in a Nutshell: An Executive Overview

I’ve been on a handful of projects that have been meant to follow the process off and on over the last 5 or 6 years. This has been with varying teams with different skill sets and levels of adoptions. The methodology has been applied with great vigor in my current project, with all the Agile methodology trappings, including: Agile Daily standup meetings Backlog Backlog grooming Story points Burn down charts Scrum master Retrospectives And other blah blah blah’s I think the thing I love most about Agile is that it recognizes Reality (capital R intended). real world solutions — even very simple solutions — for real human beings is wonderfully complex for an endless number of reasons. Designing http://agilemanifesto.org/history.html The Agile methodology appeals to people like me because it addresses this reality and provides a great process to manage this crazy complexity. It effectively responds to traditional alternatives that “ .” The thing about an irrational demand, of course, is that you simply can’t meet it, except maybe by chance. impose irrational demands through the imposition of corporate power structures But for all the hope I pour into the Agile methodology, I find myself frequently disappointed. Here are few reasons: Sprint planning sessions are simply too vague a procedure for many developers. We can never fully align on the meaning of “story point” and in many cases don’t even try. I’m personally OK with the imprecise nature and real world implication of a “story point.” Many developers, however, are not, maybe half. I’ve seen some folks more or less check out entirely because they don’t get it or like it and withdraw their intellect from the process. As a corollary to the above, this idea that “we plan, but recognize the limits of planning in a turbuluent environment” also kind of falls down for that class of developer who, for whatever reason, still believes in their heart of hearts that things can be neatly planned. The “work off the prioritized backlog until you run out of budget” thing is kind of a lie and everyone that’s been seen this movie before knows it. The real rule is “work off the prioritized backlog, but finish the whole backlog in the same budget and time as if this were a fixed project.” This means that the early sprints are relatively care free and focused on building product, infrastructure and full of high minded ideas. Intermediate sprints become a little less care free and final sprints tend toward anxiety-prone late nights, weekends and even outright panic. The final “stabilization sprint” isn’t used to stabilize things but instead to shoe horn in whatever final “must have” backlog items are still outstanding. Stand-up meetings are almost never conducted with everyone standing up. The last point seems small but it actually gets to the point of this much-longer-than-expected post :). When “Agile” projects start up, someone usually lays out the ground rules and the most easy of them all is the daily scrum meeting. They are time boxed to fifiteen minutes, team members literally stand the whole time speak to only three topics: 1) what did I do yesterday, 2) what do I hope to accomplish today and 3) am I blocked? This usually starts off OK, but at some point, someone starts sitting and then someone else does and next thing you know, it’s not “stand up meeting” anymore, it’s a “sit-down meeting.” And here is the first little crack in the process that begins the unravelling of the discipline required to really follow the Agile methodology. Next thing, people don’t just speak to their three topics. They get interrupted. Someone responds to a blocker with a suggestion and then someone else gets involved. And next thing you know, your standup meeting kind of sort of resembles a “proper” standup meeting, but is really just another random team meeting. Once we stop standing, we’ve discarded one of the most simple rules. It becomes easy to discard others. There’s a similar challenge for those more literally minded developers. I’m currently entering the 7th sprint in my current project and some of my dev colleagues continue to hold up story point estimates as a kind of shield for why a user story is taking longer or less than he thinks it should have been. Or later, during task breakdown when we finally get to man hour estimates, they’ll complain that two stories with the same story points don’t equal each other’s hour estimates. We’re going into a scrum planning session this week and I just know that for the 7th session in a row, people are still going to try and translate story points into man hours and we’re going to have the same (by now) tired discussion that story points don’t equate to dev hours. Despite all this, I still a believe that the Agile methodology is the “right” way to do things. In my heart, I also think it’s a compromise with the other “right” way to do things, which is just to do waterfall correctly :). If we can just spend the right time, with the right people to get requirements documented “just right” then we should be able to create good products. I’ve cut myself loose from waterfall because as I’ve been saying, Agile is more grounded in Reality and Reality doesn’t care what you believe in your heart. But now I’m also losing confidence in Agile as a methodology because it seems impossible to follow it, as lightweight and sensible as it is. My politics lean very left and a bunch of years ago (Jan 2009), I read a blog posting by Heather “Digby” Parton where she used the phrase, “ .” It really resonated with me and I find myself applying that phrase to non-political contexts. For instance, “Properly Implemented Waterfall Can Never Fail, Poeple Can Only Fail To Follow It.” Conservatism Can Never Fail, It Can Only Be Failed I’m a hairsbreadth away from believing the “The Agile Methodology Process Can Never Fail, People Can Only Fail To Follow It.” If only we’d during stand up meetings! If only the scrum master would concentrate on unblocking blockers and if everyone could align on the meaning of a story point! If only everyone could be at peace with the inherent problem of *needing* to estimate even when you’re missing important information. If only this! If only that! stand up It’s a disappointing thing because for me, that basically means that at a macro level, nothing is really left. Success or failure is a lot more random than I want it to be on my projects and the only way to move the dial in your favor is through some kind of Hero model, dumb luck and creative definitions of “success.” Heroic project managers. Heroic scrum masters. Heroic architects and developers. Back room deals where business compromises are made by skillful business people. That sort of thing. I’m still very invested in the Agile way because I think it’s our best hope :). Maybe it just takes more practice with a persistent team. We’ll see. do </end>

Stories, News & Mentions about AGILEMD

Agilemd’s Stories on HackerNoon