David Stannard

David Stannard


Recent posts by David Stannard

3 min read

7 steps for a painless SVN to Git migration | Praecipio Consulting

By David Stannard on Sep 10, 2021 10:24:00 AM

Blogpost-DisplayImage-September-2021_7_steps_for_a_painless_SVN_to_Git_migration

Praecipio Consulting is frequently asked about migrating from various software version control systems to Git-centered tools such as Atlassian’s Bitbucket. Excellent news time: this is definitely possible and can be done in a painless fashion! Some organizations confidently plan and migrate by themselves. But … there’s always a “but” … be forewarned - there isn’t an “easy” button. Your success depends upon investing the effort, both in planning and in communicating with your teams. However, many organizations prefer using experienced 3rd parties who will focus on doing something not considered an organizational core competency. Praecipio Consulting often assists clients in their migrations: our approach is based upon proven tools and processes honed by multiple engagements over the past 15 years. 

Nonetheless, there still isn’t an “easy” button and the client’s involvement is integral to the final outcome as unique aspects are often uncovered.

If you still use Subversion - also known as SVN - as your software version control tool, you can be forgiven in believing that you’re alone. Searching the web yields many documents from circa 2012 which often containing phrases similar to “… 90% of developers have already migrated to Git …”. However, as recently as 2018, literature also indicates that SVN is still used because its users value its strengths over Git.

So say your organization has a business need to switch from SVN to Git. This might be because your organization has distributed development teams, or maybe the usage of SVN negatively impacts attracting new developers who expect a distributed version control tool such as Git or Mercurial.

Bottom line: you need to adopt Git and also migrate some or all of the information contained in SVN to Git; this blog assumes this means a codebase.

To better understand the implications of a migration - I suggest Stefan Holm Olsen’s explanation. Stefan led the migration of an 11 year old SVN, commercial grade codebase to a new Git codebase. All while continuing active development (https://stefanolsen.com/posts/migration-from-subversion-svn-to-git/ and https://www.atlassian.com/blog/git/atlassian-svn-to-git-migration-technical-side).

Atlassian documents a simpler case of a single SVN subfolder being migrated to a new Git repository (https://www.atlassian.com/git/tutorials/svn-to-git-prepping-your-team-migration) This may be sufficient for some do-it-yourself organizations.

In either case, it helps that the migration team understands how Git works and also the differences between Git and SVN. (If not, I suggest a quick detour to https://docs.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github/what-are-the-differences-between-subversion-and-git and https://git.wiki.kernel.org/index.php/GitSvnComparison.) Most software engineers and developers are already familiar with Git - hence the examples address the potential SVN knowledge gap.

Stefan described a 5-step general process. The following 7-step process results from adding a preliminary step, because similar to Agile, the human aspect is primordial. Having an internal champion or two will certainly help increase the odds of a successful migration. An intermediate Git repo step is also added, although the brave may choose to go directly to the final destination. Like any undertaking, communications and scheduling are critical.

  1. Plan your migration including the often overlooked human considerations:
     - What can remain in SVN? What can / can’t be lost?
     - Understand the impact to release notes and governance
     - Identify the impact to your CI/CD environment
     - Determine the timing of the actual migration (weekend, overnight, etc)
     - Train users on how to effectively employ Git
     - The comms plan: who’s communicating, how, and the regularity of the updates
  2. Identify users and their correct names pre & post migration
  3. Choose a location for your Git repository
  4. Prune the SVN codebase
     - Address multiple folders in SVN repositories
     - Thoughtful pruning of folders, files, old and unneeded branches
  5. Create an intermediate repository to support the migration
  6. Migrate from SVN to the intermediate Git repo
  7. Migrate from the intermediate Git repo to the target production repo

Migrating from SVN to Git should not be feared. There are known processes when migrating from source code systems. Some planning and a lot of communicating will go a long ways towards a successful migration. If you need an expert hand in planning and executing your migration, contact us, we would love to help!

Topics: blog best-practices migrations plan repositories svn git custom-development
3 min read

Old Is New Again – Conversations Over Documentation

By David Stannard on Jun 18, 2021 11:43:00 AM

Blogpost-DisplayImage-June_Old is new again - Conversations over DocumentationImagine a world where businesses can concurrently develop next generation manufacturing processes while designing products based upon the as-yet-non-existent implementation medium. Imagine that they can do this all while reducing time-to-market and allowing the continued benefit of exponential growth in complexity every 18 months. Add a twist of “design-anywhere-build-anywhere” – and serve shaken; not stirred. Perhaps in software, the analogy might be "develop applications on a language being implemented and SDKs that will also be created concurrently – trust us, it will be fine." At the same time, many graduates from engineering colleges were learning that the soft skills of communication and collaboration had higher impact to their success than the hard earned technical skills.

In the early 1990s, an organization is asked by several of its clients to help them address time-to-market pressures. The result: in 1992 Don Carter published a book founded upon a transformational approach called Concurrent Engineering based on consulting experiences. One impact that I remember well was the increase in actual conversations amongst the various constituents - breaking down the barriers between the silos was a key component of this philosophy. Coincidentally, the quality of results increased too, along with client satisfaction.

Back to the future... Literally!

There is even more pressure on businesses to reduce time-to-market, and there are few signs that this will change or needs to change. No time for creating voluminous documentation in semi-isolation that can't capture all aspects and are often subject to interpretation by the reader. The division between hardware and software development has blurred. In fact, hardware designs are created, modeled, emulated, and the proposed implementations are verified using specialized high level languages prior to implementation. The abstracts are subsequently decomposed into manufacturable entities while continuously confirming no unintended loss of the design intent using specialized tools such as formal verification tools. 

Businesses are and must continue becoming Agile – businesses are greater than having Agile development organizations. So the adoption of Agile, Scrum, and other practices continues unabated. There are even early discussions of what’s beyond these Agile practices that are standing the test of time after several decades of adoption. 

Two important aspects of the Agile Manifesto are valuing “Individuals and interactions over processes and tools” and “Customer collaboration over contract negotiation”. It was increasingly common pre-COVID that these teams were distributed geographically and even culturally. So while tools are a part of the solution – the need to communicate well and often has never been more important. This practice is standing the test of time.

A closing note to Scrum Masters who help teams live the benefit of the cross-functionality objective: Your Scrum teacher and Agile coaches have provided you with lots of reference material about building teams and communications. Now is a good time to revisit those references; one of my favorites is “Crucial Conversations” by Kerry Patterson et al. The book addresses situations with perceived high stakes, diverse constituents, and possibly highly emotions.

Looking for more Scrum tips? Check out Sprint Planning: How Long Should Sprints Be? or Kanban vs. Scrum: Which One and Why? and contact us, we love to help!

Topics: scrum collaboration documentation agile software-development
3 min read

Scrum Master Basics – Part 2 of 3: The Definition of “Done”

By David Stannard on Jun 11, 2021 9:45:00 AM

Blogpost-DisplayImage-June_New to Scrum Master Role Guide–Part2TheDefinitionofDoneThis is Part 2 of a series of 3 posts on Scrum Master Basics.  Here is Part 1

I have to admit, I’m biased. As a manager and a business person, I have a vested interest in my teams success. That success is built upon them achieving a sustainable pace of delivering value to paying clients while supporting their personal growth. 

The definition of “done” is a powerful tool. In my journey as an Agile Coach and Scrum Master, I have found that focusing on the team’s definition of ‘Done’ provides tremendous return on effort. If your team jokes about ‘Done’, ‘Done done’, and ‘Done, done, done’ - there is usually a gold mine of opportunity for continuous improvement.

I believe in the strong relationship between defining done and improving a team’s overall well being – I've seen it first hand. Conversely, I see high dissatisfaction within the team, from the Product Owner and people outside the team when there isn’t a clear definition. In the knowledge business, people like to create and provide things that others use; they generally hate building the wrong thing or things that aren’t wanted or used.

Here are a couple of real world examples from teams I've worked with:

1st example from a real demoralized team:

Scrum Team: “We define ‘done’ as the feature being ready for QA to test.”

Scrum Master: This is clearly an anti-pattern to delivering a potentially releasable unit of value. We’re doing Wagile, not Scrum!

Expunge that way of thinking permanently and never say it – ever!  Seek first to understand…

A Scrum Master should always assume that people are rational and therefore behave rationally. Dig into the reason for the definition. Perhaps this was the team establishing a working agreement based upon having a lone QA person and this was seen as a solution not a problem. I bet that they’d love some help that can result from simply asking “what can we do as a team to help you with your workload?See the world from their perspective. They may be transitioning from classical waterfall workflows and the team hasn’t adjusted to the concept of a cross-functional team.

Use the principle of “take it to the team”.

How can we (the Scrum team) help you? Help ourselves?

Scrum Masters also use individual 1-on-1 coaching – How can the team and/or I help you?

2nd example from a real team:

Scrum Team: “We define ‘done’ as the feature being implemented, passing tests, and meeting the acceptance criteria – but we never release anything.”

Finding possible root causes is again key. Problem solving requires an agreed upon statement of the problem and the desired outcome from a change. In this case – it appears that it is potentially releasable, so the team may have a variety of options such as exploring:

  • What is (are) the root cause(s)? Where does the team have the capability?
  • Discussing with the Product Owner as to why value isn’t being released?
  • What if we did a dark release so that we can keep our release ‘muscles’ toned?

Please note that the 3rd bulleted item shifted to exploring possible solutions. 

Two parting questions:

  • When should these discussions occur?
  • Who should be involved?

If you're wondering if Agile is a good fit for your organization, or have any questions on Scrum methods, contact us, we would be delighted to help.

Topics: blog scrum tips project-management agile
2 min read

Scrum Master Basics – Part 1 of 3

By David Stannard on Jun 3, 2021 10:13:00 AM

Blogpost-DisplayImage-June_New to Scrum Master Role Guide – Part 1 (2)

Congratulations on becoming a Scrum Master (SM)!

Scrum is a tool that builds teams. It exposes the issues but not the causes and solutions. A Scrum Master helps their team grow through continuous improvement & collaboration. 

As a builder of teams, I’ve often seen smart employees and colleagues return from training and struggle with how to apply their new knowledge. Most often, failure occurs when the returning person takes an approach of telling people what to do and why the current approach is wrong.


Hence this 3 part blog series.

Some of the chief motivations for choosing Scrum are:

  • Delivering potentially releasable value at a regular cadence

  • Being responsive to change instead of steadfastly sticking to a plan

  • Eliminating waste / becoming leaner

  • Collaboration with clients instead of dry, incomplete, ambiguous contracts

In existing organizations, I’ve seen more successful outcomes and happiness when taking the “Start Small” approach. Mike Cohn in his book “Succeeding with Agile” observes “...there can be no end state in a process that calls for continuous improvement...”. 

Therefore, take incremental steps with your team – leave grandiose visions to the C-level. This increases the probability of success, which breeds confidence and momentum while reducing risk and investment. Similar to software development, your emotional stake in an incremental effort is much lower than multiple weeks of time investment; you’ll more easily throw away an approach that isn’t working. Your team learns experientially which requires trying, learning, adjusting, and growing together. Your team is a living system – so probe, observe, and adjust.

The noun “teams” is key. A Scrum Master’s success ultimately depends upon their ability to help them. You will require patience, the desire to learn about how to build teams, and a firm commitment to the values and principles of Agile. 

Assuming that you’re joining an existing team, here are a few concrete actions:

  • You’re about to change the dynamics of an existing team. So Meet the current SM and discuss the transition prior to showing up to the team’s ceremonies

  • Ideally, be invited to the ceremonies: attend – observe and assure the team that you aren’t planning any unilateral changes

  • Gain access to and review your team’s working agreement. Specifically – the definition of ‘Done’ - more in Part 2

  • Study their sprint board – more in Part 3

And remember – as Stephen Covey writes in The 7 Habits of Highly Effective People – "Seek first to understand not to be understood"

If you're wondering if Agile is a good fit for your organization, or have any questions on Scrum methods, contact us, we would be delighted to help.

Topics: blog scrum tips project-management agile
2 min read

Business Processes & MIT's Beer Game

By David Stannard on Oct 19, 2020 12:53:00 PM

Blogpost-display-image_COVID-19 – MIT’s Beer Game in Operation2

It has been said that one’s true character is exposed during times of crisis. Crises can also serve as an opportunity to compare theory against in situ behaviors, setting the stage for continuous improvement. 

In 1990 MIT lecturer, Peter Senge, released his book The Fifth Discipline, which was extremely influential for learning organizations. For me, it was my second encounter with MIT’s work on systems and the first non-engineering book that influenced the way I look at the world. Systems thinking is the fifth discipline that integrates the other four disciplines: personal mastery, mental models, building shared vision, and team learning.

Senge’s book summarized MIT’s “Beer Game” that MIT developed in the 1950s as a means to introduce dynamic system concepts. It describes what happens when a particular brand of beer suddenly experiences an unexpected upswing in demand. The game shows the difficulty in managing dynamic systems, and for this particular case, the supply chain for a single product – beer. I highly recommend reading the chapter or trying one of the simulations.

Reading The Fifth Discipline and using the simulation is one way to learn about dynamic systems. Another way to learn is just by living through this year, which has been synonymous with massive disruption and additional layers of complexity. It has provided us with the opportunity to directly experience the Beer Game for multiple products and multiple supply chains in real-time. So where was the missing toilet paper earlier this year? The missing Clorox wipes? The missing hand sanitizer? Did this only affect me? What about elsewhere? We may have mastered just-in-time supply chains and practices–complete with elegant models and all–but supply chains are in fact much more dynamic and complex. 

The average American family consumes 139 rolls of toilet paper annually year. Nice, boring, and predictable – just the way forecasters like it. Also, I’ve learned that toilet paper is a low margin business that is manufactured infrequently because of the forecasting’s reliability. 

Two of The Fifth Discipline’s eleven principles may provide insight: "today’s problems arise from previous choice” and "the harder you push the system, the harder it pushes back.” We have experienced unexpected shocks to the system this year, which has been further complicated by unpredictable consumer behavior. Consumers reacted by hoarding and impulsively buying substitutes for out-of-stock products, effectively magnifying the effects of a system under stress. 

During conversations with relatives residing in Germany, Serbia, Canada, and New Zealand, I learned that they didn't experience these shortages. Perhaps this is reasonable since they have different supply chains (or maybe we can blame the use of the metric system).

In 1997, Harvard Business Review recognized The Fifth Discipline as “one of the seminal management books of the past 75 years," and even though it's been 30 years since it was published, Senge's book is still relevant for those wanting to improve organizational performance. I recommend listening to the audio version or reading the text - it’s well worth the read.

Businesses everywhere have had the rug pulled from under them, and if you have faced challenges with your supply chain (or any other areas of your business), Praecipio Consulting can help with our tech-enabled business process solutions. Let us know how we can support you!

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us