The Agility Guide to Evidence-Based Change: Using Scrum to Transform Your Enterprise

Many organizations want to gain a competitive advantage by improving the value they derive from software development. They desire to take advantage of opportunities, respond effectively and deliberately to challenges, all while controlling risk and optimizing the return on investment. These organizations often turn to Agile processes such as Scrum, and embrace initiatives to become […]

Getting started with a modern source control system and DevOps

Martin Hinshelwood·FollowPublished innaked Agility from Martin Hinshelwood·8 min read·Nov 10, 2017–There are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code, but modern source control systems are about way more than code. They are about your entire application lifecycle and supporting DevOps practices, they are about the metadata that you use to understand and manage your development processes and deliver great software. The tools you choose should compliment the professional people and practices that you use.DevOps is the union of people, processes, and practices to enable continious delivery of value to your end usersDonovan BrownTL;DRI have been teaching the Professional Scrum Developer (PSD) training and working with software teams for 7 years. I have never encountered a better platform than Visual Studio Team Services (VSTS) for managing the metadata required to facilitate the building of professional software on a regular cadence in any technology that is deployed to any platform. I have seen Java, .NET, Web, Android, iOS, and Mainframe teams all working together in VSTS with a shared vision and access to the same metadata. If you have many teams I did a webcast for Scrum.org on Scaling Professional Scrum with VSTS.Let’s get some things out the way firstIf you are writing code then it SHOULD be in Source Control. More specifically, if you are writing code for your company then it MUST be in Source Control. Every line of code that you write or change is an asset of your organisation and should be reflected on a balance sheet somewhere. Any value you add is capital expenditure, of which your shareholders/owners should care, and any maintenance is operational expenditure, which your accountants can write off.Put your code in source control… and yes, I still meet organisations that DON’T use source control. No, not only small sweatshops but banks as well. Would you want your real-time transactional banking system under source control? Coz I would!Another thing to get out of the way is that deploying directly to production is a BAD IDEA! If you are deploying from your local workstation then you are introducing significant risk to your business and reducing the quality of the organisational asset. Any reduction of quality is a decision that needs to be taken by your executive board on advice from your accountant. Again, organisational asses sitting on a balance sheet. Its fraud to incorrectly represent the value of an asset, ignorance is not an excuse. Even if you have automated builds; if you ship irregularly, or with a lot of time between releases, then you likely have a way to bug-fix production quickly. Bypassing your usual checks and balances for shipping software reduces quality and shows an inherent lack of engineering excellence in your organisation.Deploy software through an automated release pipeline… and yes, I have met companies that deploy directly to production from workstations. I even worked with one company that had operations using trial and error mixing and matching DLL’s to get the software working in production. One customer required to do 9000+ hours of manual testing to validate thatModern source control is more than just code… in the past, just like operating systems used to be simple things, you could stick your code in source control and call it good. In the past, you used VSS, Subversion, or Perforce and it was good enough. Not anymore. Just as you expect a browser to ship with your OS, you now expect a build engine, release management, and planning tools to ship with your source control system and for them all to be integrated. So don’t base your choice on that one thing, think of the integration and other tools that you need to support your modern software development pipeline.I would expect my release tools to understand exactly; what changes have been made to the code, which features of the system are affected, and what the resulting impact of that release had on both the user experience and system performance through telemetry. I would expect my work tracking tools to understand exactly; what branches are related to this work, which build include the changes, and who approved the pull requests that brought that code into the system. This is the type of metadata, regardless of the implementation technology, that I would expect to be available to Engineering and Management to help them understand their process and how things are going.That all said it is important to remember to focus on becoming a professional Scrum team rather than an amateur one. While you need to focus on the Scrum Guide, you also need Engineering Excellence and a set of Values and Principles.Recommended good practices for a modern software teamI almost never use the term “best practices”, especially for software delivery and anyone that gives you a best practice is generally talking out their ass. There are only good practices that fit the current needs of the business or the situation at hand. In the modern software development world, you need to accept that any process or practice that you adopt is imperfectly defined and will need to be adapted to meet your needs. That said, having source control and an automated release pipeline is not optional if you want to continue to be competitive. You need to be able to monitor both your Lead Time and your Cycle Time.Some general guidelines you should consider:Never code without Source Control — Ultimately the tool does not matter but if you are building Open Source Software (OSS) then you need to be on GitHub. GitHub has cornered the OSS market and has not near competitor. If however, you are building closed source software then there is no better platform than Visual Studio Team Services (VSTS). You get unlimited private repositories and if you have MSDN licences, as most organisations building on the Microsoft stack does, then it is already included in your licence. If you are not on the Microsoft Stack then I would still recommend VSTS as the cheapest and most featureful platform available that supports any platform and any environment.Use feature flags to minimise branches — Branches introduce waste with merging and often introduce quality issues. Bypass the whole issue by using Feature flags and other software patterns to avoid it. If you are using a distributed source control system (DVCS) only ever release from MASTER with fully tested code, but you can have an unlimited number of topic and personal branches, as long as they are short lived. If you are using a server-based source control system (SVCS) then you should completely avoid branches where possible, and work to move towards a DVCS. Maybe you need only [trunk/master/main] and [dev/work] branches but focus on a zero branch policy.Move to Git — Regardless of the scale of the software that you are building, you should be developing on Git. If you are clinging to your SVCS (TFVC, Perforce, SVN, whatever) then you are merely clinging to the past and relying on outmoded technology. Even the Windows team at Microsoft has moved to Git, as has Bing, Xbox, & the entire Developer Division.Meet your Definition of Done at least every 30 days — Create a definition of done that represents the minimum bar of quality for everything your develop. Make sure that definition reflects everything that you need to do to ship your software to production, and get there at least every 30 days. If you can get there more regularly that better, and if you can practice continuous delivery inside of your planning Sprints then that’s even better.Get feedback from your users at least every 30 days — Part of the trick of delivering awesome software is building just what your customers need, just as they need it. The only way to do this is to get what you have just built into your customer’s hands so they can tell you is it is right, then pivot as soon as they give you feedback. Continuous delivery to production is the best way to achieve this.Create tests first so you build what was asked the first time — You should always work towards test-first practices. While for many this means Test Driven Development (TDD) I like to look it as any form of test-first. How can your coders ever hope to pass the quality gates when the testers build the test cases separately and only show the coders after they are finished. Get your test cases written first and have the coders make them pass. I also recommend that coders use TDD and pair programming. Following Test First will help you move from testing quality in at the end to building quality in from the start.Automate every test you can — Automation is key to a successful delivery because you can’t run all your tests every 30 days. Every 30 days you add more tests and without automation, you can’t keep up. Ideally, all of your tests are automated from the start. An interesting example is that Microsoft moved all of its testing efforts into the Development Teams around 3 years ago, and got rid of their last external test team about 2 years ago. Make your Development Team(s) accountable for Quality and give them the tools to make it happen.Create automated release pipeline — Creating an automated release pipeline is hard but the benefits are numerable. From quality to resilience you just must have one to support modern development practices. You should focus on delivering to production (start with as close as you can get) at least every 30 days, but expect to need to ship many times a day. Automation will make your process quick and easy an lets you focus on improving the pipeline over time as you his issues. This is where lean practices and focusing on flow can really help minimise the waste and improve the process.In order to support these things, I use VSTS as my software development platform. With the move by Microsoft to distance its platform from execution and focus on orchestration we get a system that can support any team developing with any technology for any platform. This allows us to have a single unified organisational vision and tool for our orchestration of portfolio, planning, execution, coding, build, test management, and release while leaving the execution of these tasks and the technologies used in and to build our software up to the team. You might have one team that used Nuget and another than uses NPM, or one using Maven and another on Gulp. Regardless of your implementation choice, VSTS can support your teams doing Scrum and deploying anything on a regular cadence to anywhere. When I am teaching a Professional Scrum Developer (PSD) class I always use VSTS regardless of the technology that the students are working on.Don’t get locked into a limited set of technologies, VSTS supports every technology on every platform.Who is naked Agility Limited — Martin HinshelwoodMartin Hinshelwood is the Founder/CEO of naked Agility Limited and has been their Principal Consultant and Trainer on DevOps & Agility for four years. Martin is a Professional Scrum Trainer, Microsoft MVP: Visual Studio and Development Technologies, and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010 and has been delivering software since 2000. Martin is available for private consulting and training worldwide and has many public classes across the globe.Originally published at nkdagility.com on November 10, 2017.Martin Hinshelwoodinnaked Agility from Martin HinshelwoodHow do you handle conflict in a Scrum Team?As part of the Scrum.org webinar “Ask a Professional Scrum Trainer — Martin Hinshelwood — Answering Your Most Pressing Scrum Questions” I…3 min read·Oct 7, 2019–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodThe Dumpster fire of SAFe!SAFe has done irreparable damage to many companies like Volvo & Fitbit. Do not take their case studies at face value!2 min read·Jun 25, 2022–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodWhat my father taught me about Evidence-based Management (34 years before it was invented!)A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to hone my skills as an Evidence-based…7 min read·Mar 20, 2014–Martin HinshelwoodWhat is Taylorism, and why Waterfall is just the tip of the iceberg!For many people the traditional project management methodologies (see PMI / PRINCE2) are the root of the problems that birthed Waterfall…11 min read·Jan 18, 2021–Vaishnav ManojinDataX JournalJSON is incredibly slow: Here’s What’s Faster!Unlocking the Need for Speed: Optimizing JSON Performance for Lightning-Fast Apps and Finding Alternatives to it!16 min read·Sep 28, 2023–167Artturi JalliI Built an App in 6 Hours that Makes $1,500/MoCopy my strategy!·3 min read·Jan 23, 2024–167Surapu Purushotham ReddyPerformance Testing – ToolsChoosing the right performance testing tool is an investment in the success and user experience of your application. There is no one-size…4 min read·Jan 17, 2024–Alexandru LazarinILLUMINATIONTen Habits that will get you ahead of 99% of PeopleImprove your life and get ahead of your peers in 10 simple steps9 min read·Nov 18, 2023–392Benoit RuizinBetter ProgrammingAdvice From a Software Engineer With 8 Years of ExperiencePractical tips for those who want to advance in their careers22 min read·Mar 20, 2023–270Gowtham OletiApps I Use And Why You Should Too.Let’s skip past the usual suspects like YouTube, WhatsApp and Instagram. I want to share with you some less familiar apps that have become…10 min read·Nov 14, 2023–353

No Estimates and is it advisable for a Scrum Team to adopt it?

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer – Martin Hinshelwood – Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those […]

Professional Scrum Training for the Ghana Police Service

Last time I talked about the Ghana Police Service (GPS) I was talking about Professional Organisational Change and the approach the Inspector General of Police (IGP) is taking; using Scrum to incrementally make changes to the organisation. While Nana Abban and the IGP have been focusing on the big picture, I have been in Ghana […]

NDC London 2014: Why TFS no longer sucks and VSO is awesome

I was in London last week to do a talk on why TFS no longer sucks entitled “Second Look, Team Foundation Server & VSO”. I had a tone of preparatory work to do too make the demos smooth. The great god Murphy was however not smiling, but he was not angry. Some errors occurred, but no blue screens. […]

Are you doing Scrum? Really?

This week I was at the ALM Summit in Redmond. There was a very interesting talk from David Starr of Scrum.org going over the recent changes in Scrum. These changes are, I think, designed to battle the things that have made Scrum unpalatable to many people. The reality is that many people and organisation are […]