index.json

[{"categories":["continuous delivery"],"contents":"Yesterday, I presented on \u0026ldquo;Making CD happen\u0026rdquo; at the ThoughtWorks Talks Tech March 2019 edition at the ThoughtWorks Singapore office\n .\nI use slides to support my message, so there is sometimes context around the various slides.\nOver the past few years, organisations have been increasingly recognising that along with governance and project management (read, scrum), they need to pay attention to engineering practices too. The result has been an increasting move to achieve Continuous Delivery (or \u0026ldquo;CI/CD\u0026rdquo; as it is unfortunately often also known).\nThe reality is that the IT budget went into expensive scrum and \u0026ldquo;CI/CD\u0026rdquo; tool implementations, dedicated staff, and so on.\nWith a plethora of tools and consultants, lots of tutorials and IT budgets assigned to such initiatives, there are a lot of implementations out there which are not yet delivering results.\n There are still defects in production There is a lot of wait-time between code-commit to go-live Triaging defects continues to take time Integration between workstreams continues to be risky Fixing a defect doesn’t guarantee that nothing else got broken Changes pushed to prod often leads to failures What works in one environment doesn’t work in others  To quote from the Continous Delivery explanation at Martin\u0026rsquo;s website (a informative 1 pager; he points us to Jez Humble\u0026rsquo;s original website on Continuous Delivery too):\nquote:\nYou’re doing continuous delivery when: [1]\n Your software is deployable throughout its lifecycle Your team prioritizes keeping the software deployable over working on new features Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them You can perform push-button deployments of any version of the software to any environment on demand  end quote\nIn this talk, I covered some of what it takes to make Continuous Delivery happen.\nOne cannot just install a CI server, link it with Jira, set up some jobs, and then declare \u0026ldquo;CI/CD is in place!!\u0026rdquo;. There is a lot of engineering, process optimisation and collaboration that is needed.\n","permalink":"https://www.sriramnarayanan.com/making-continuous-delivery-happen-thoughtworks-talks-tech-march-2019/","tags":["cd","cicd","continuousdelivery","agile"],"title":"Making Continuous Delivery happen - ThoughtWorks Talks Tech March 2019"},{"categories":["management"],"contents":"Today, I presented at Cloud Asia Singapore 2018 on the topic \u0026ldquo;Migrating your IT policies to the Cloud\u0026rdquo;.\n  Moving to the Cloud is more than just getting an account at a public cloud. Even a lift and shift approach needs quite some thought to the design.\nQuickstarts and readymade scripts help us get started. There are external consultants available to provide all manner of technical advice too. However, there still are various decisions that the IT Manager and the Organisation have to still take on their own.\nThese fall in the areas of: * Migrating from Capex to Opex\n Giving control to teams to manage their own infrastructure\n Establishing a Governance model that caters tofinancial and security safeguards while leveraging the flexibility that prompted the move to the Cloud in the first place\n Amending the IT policies to recognise that the traditional application architectures won\u0026rsquo;t work any more. For e.g., Cloud-native apps and Cloud based technologies would push the so-called \u0026ldquo;Web Tier\u0026rdquo; across 3 to 4 different Cloud components. As another example, the firewall rules are now implicit in the network policy settings, effectively providing the same source-destination IP and port level control that in-house infrastructure facilitated.\n Rather than rushing to massively downsize the IT team, use them for the many things that you still need your team for as per the shared responsibility model of all public cloud providers.\n  This talk covered all these and more. The slides that I\u0026rsquo;ve shared above are descriptive to quite some extent.\nThis is also the gist of my upcoming book of the same name.\n","permalink":"https://www.sriramnarayanan.com/talk-migrating-your-it-policies-to-the-cloud/","tags":["cloud","layoffs","migration"],"title":"Talk - Migrating your IT policies to the Cloud"},{"categories":["agile"],"contents":"See my slide deck that I usually use when giving a talk on this topic.\nAmong the many practices that people start to follow when they decide to \u0026ldquo;go agile\u0026rdquo;, is the daily standup.\nJason Yip\u0026rsquo;s article on standups is often considered the reference article (that\u0026rsquo;s me in the red t-shirt in that pic).\nOver the years, various organisations and teams have adopted the practice of a standup along with many other practices in the hopes of being Agile. As an outside observer, I often get to spot various anti-patterns in standup practices.\nHere are some standup anti-patterns to identify and address:\n1 Having a person \u0026ldquo;run\u0026rdquo; the standup It is best that people volunteer information turn by turn, rather than be asked to. This way, people learn how to discuss during ad-hoc standups.\n2 Reporting to an authority figure People tend to naturally \u0026ldquo;report to the Natural Leader(s)\u0026rdquo;. Such leaders may be one or more persons who make things happen, or set direction or solve problems. This reporting is often by way of looking at the leader(s) when speaking.\nIdeally, a team should be used to functioning in the absence of the leader. This helps keep the show running, and the team or smaller focused groups within the team gain the confidence and experience to call for an ad-hoc standup to discuss matters.\nIt is, therefore, best that a person giving a standup update look at everyone in the team. Likewise, it is important that the team actively ask the speaker to address everyone in the group and not just the leader. Depending upon the team dynamics, you could choose between calling this out as it is happening, or taking the person aside and giving them feedback, or announcing at the start of the standup.\n3 Treating the standup as a \u0026ldquo;reporting mechanism\u0026rdquo; A common technique used to get someone to become subservient to you is to ask them about six questions. The act of replying consecutively (especially over a period of time and/or in others\u0026rsquo; presence), makes people start to \u0026ldquo;report to you\u0026rdquo;.\nThis is both mean as well as an inefficient use of the team\u0026rsquo;s time. It is better that story and issue tracking systems and CI dashboards provide the project\u0026rsquo;s state, while the standup focus on blockers, emergency items, stuck items, other priority items\nThis also requires that people come to the standup prepared on these four items.\n4 Sharing updates only at the standup and not earlier It may happen that a team member may notice something, and decide to share this at the next standup - which may very well be the next day! This wastes time.\nIt is instead better to share one\u0026rsquo;s observation (\u0026ldquo;right now\u0026rdquo; is often the right time to share), and seek help. One can also call for \u0026ldquo;huddles\u0026rdquo;, where devs who have context or can provide advice gather together for a quick discussion on the finding or the query, and step away once they are no longer useful. This helps ensure that queries are addressed as early as possible. This saves time and money for the team and for the client.\n5 Limiting the team to just one standup a day Word \u0026ldquo;daily\u0026rdquo; in \u0026ldquo;daily standup\u0026rdquo; leads one to believe that there can be just one standup a day. Further, treating the standup as a reporting mechanism further conditions the team to \u0026ldquo;follow the leader/facilitator\u0026rdquo;.\nWe should bear in mind that one can have as many or as few standups as one wants. For e.g. during a production issue, one might have a standup every hour as a checkpoint. This could be an ad-hoc standup amongst the problem solvers without any facilitator necessarily needed.\n6 Using standup time to signify the start of the day If a team follows the concept of \u0026ldquo;core working hours\u0026rdquo; - a 6-hour window during which everyone is present together, this enables different people to have different timings. Once we add multiple-standups-a-day to the mix, we can no longer \u0026ldquo;start the day\u0026rdquo; with a standup. It is better to focus on the outcome of the day and the progress made, rather than trying to \u0026ldquo;discipline the team\u0026rdquo; by starting the day with a standup.\n7 Missing the standup Once the team decides on a standup time, it is best to respect the team decision and make it to the standup on time. Not doing so is a disrespect to the team, one misses out on receiving and providing information, and this starts off a culture of not caring. While one can provide standup updates via phone call and chat, it is best to not miss the standup itself. One could also have a standup a time convenient to all.\nBut do bear in mind maker schedule, manager schedule\n8 Others not respecting that a standup is in progress If you see another standup in progress, pause your chatter while they finish. Otherwise, you\u0026rsquo;ll just add to the general noise, everyone would increase their volume, and the place becomes noisy.\n9 Detailed discussions at the standup A standup is for quickly stating blockers, emergency items, stuck items, other priority items. If something needs to be discussed at further depth, then finish the standup and have that discussion.\n10 Bringing offtopic items during the standup It is best to finish the standup and to then share non-standup information, make announcements, etc. This helps the team finish the standup.\n11 Expecting (Or Requiring!) that everyone provides a standup update A common social engineering approach to expose those who are not working, is to demand a standup update from them. While this approach has it\u0026rsquo;s use and place, embarrassing someone at a standup is not the way to go about. There can be various reasons a person may either not be working at all, or may be perceived to not be working. Standups should be efficient, focusing on blockers, calls for help and other priority items. All other agenda should be executed in other ways.\n12 A standup that takes longer than 10 minutes Remember, it is not wrong to have discussions. It is more efficient to first gather the summarised points, and to then break off into smaller discussion groups.\nI\u0026rsquo;ve been part of teams of 40 where there is a general standup that gets over within 10 minutes, followed by tech, BA , infra and other focused groups standups and discussions.\n","permalink":"https://www.sriramnarayanan.com/some-standup-anti-patterns/","tags":["agile","standups"],"title":"Some standup anti-patterns"},{"categories":["agile"],"contents":"Here is the slide deck to a popular talk that I give on standups. I recommend that you also read the accompanying article.\n  ","permalink":"https://www.sriramnarayanan.com/talk-on-standups/","tags":["agile","standups"],"title":"Talk - On Standups"},{"categories":[],"contents":"Today, I presented on \u0026ldquo;Segregation of Duties and Continuous Delivery\u0026rdquo; at the DevSecCon Singapore 2017.\n  The talk was well received.\nAs per the wikipedia article on [https://en.wikipedia.org/wiki/Separation_of_duties], \u0026ldquo; In business the separation by sharing of more than one individual in one single task is an internal control intended to prevent fraud and error.\u0026rdquo;\nIn the I.T. space, the approaches for implementing Segregation of Duties are very defensive in nature. While the objectives of SoD are arguably achieved, the present enforcement approaches slow down the overall time from code commit to production deployment. This prevent effective Continuous Delivery.\nIn my talk, I present the intent, the current approaches, and my recommended alternative approaches.\nThis talk with be one of the chapters of my upcoming book on Security and Continuous Delivery.\n","permalink":"https://www.sriramnarayanan.com/segregation-of-duties-and-continuous-delivery/","tags":[],"title":"segregation of duties and continuous delivery"},{"categories":[],"contents":"I\u0026rsquo;ve decided to try static website hosting using Hugo.\nMy earlier blog can be accessed here\n","permalink":"https://www.sriramnarayanan.com/migrating-to-a-static-website/","tags":[],"title":"migrating to a static website"},{"categories":null,"contents":"","permalink":"https://www.sriramnarayanan.com/search/","tags":null,"title":"Search Results"}]