Why does a scrummaster need to know about Engineering Practices?
By Anil Jaising Published On September 9, 2021
I coded for most of my career and now I am more of a hacker of code that can get things done instead of being a pure coder. In the early 1990s, as a five member team we did everything to deliver the product into the customer’s hands including working with users on requirements, write code, conduct all types of testing and support a messaging platform on 40 servers that would send messages across the world in 3 seconds .In the early 2000’s I attended a Certified Scrum Master® (CSM®) Workshop, the experience brought me back to the 1990s and removed the frustrations I was feeling working in Silos and struggling with the nuances of a plan that could not change and non existent engineering practices. I instantly quit a well paying job and starting consulting as a Scrum Master for a mid size bank.
As a Scrum Master of a scrum team with a product owner and 7 other team members including two business analysts and 5 members who wrote code. The team (TeamFAST) was hand picked by management and were given all the resources to be successful. They were trained and also coached by a very reputable coach. I was lucky to be a scrum master hired into this team and found myself learning as well as imparting my knowledge of software delivery to the team, the product owner and the management. We had our own open area, video conferencing equipment, our team area was equipped with large monitors and as a consultant I even had an expense account.
Everything was great except one thing, there were several bugs being raised by users that were not caught in testing by the coders. The obvious solution….hire a tester. Wrong!!
Being technical gave me the advantage of knowing XP or extreme programming and I knew all the technical practices that came with it. As a scrum master I of course knew that I could not tell them what I knew but wanted the team to come up with their own answers. I conducted a retrospective focused on bugs and used the five why’s technique to better understand the root cause. From the root cause analysis came solutions from the team: Further break down features, unit testing, a lot more pair programming, etc. and the team picked a few of these and went down the path of improving their practices.
So should the scrum master be technical like I was? Not really, they should be aware of these practices and how can they be applied.
So do these practices only apply to software development?
Well they started in software development, but actually they make sense to use in any industry
So what are these practices? Tell me more… But make it real easy for me to understand. Please!!
Let’s take a simple scenario: Let’s say that two partners are collaborating on co-authoring a book and one of them lives in New York City and the other in San Francisco, CA. They choose google docs to write their chapters, some chapters are exclusively written by one author and others they co-write. Eventually they like to finish the book and publish it.
Small Releases
According to Ron Jefferies, This should be considered a “beginner” practice. If you take my scenario, many authors write each chapter as a blog and release it every one or two weeks. Many authors release a few chapters at a time as a sample to a limited audience and also release it to their editors, etc. This is the practice of small releases, getting feedback and continue to improve their overall book.. In one of the large investment banks that I worked with, a trading platform software was released every two days. What do I mean by “released”? In the case of the bank, the team would ship it to the users a product that is fully integrated, fully tested, documented and users are ready to use it.. In other cases I have seen teams release to internal stakeholders or a chosen pilot users.
Small Releases are small steps on the way to Continuous Delivery, a step beyond the old Continuous Integration.
Continuous Delivery
In my scenario, the partners always have one chapter of their book fully written, integrating their own paragraphs,, edited and ready to be published. Whether they actually publish it’s upto them. Many software teams use tools to help them keep their software code fully integrated, tested and ready to be delivered. The team always has a ready-to-ship Increment,
Pair Programming
One of the best ways to improve quality of any work is to pair with someone else. If the authors get on a conference call, share screen and one person writes and the other person is watching and helping improve or review something that has already written.
In Software development this practice is so important, I have see organizations invest in stations where there are two seats with one computer, keyboard and mouse, two screens and two team members work together on writing code, tests and running tests to validate what they coded. As mistakes are made, the pair can help review and correct. The quality of the code written and hence the quality of the overall product goes really high with this practice
Coding Standard
In the beginning the partners agree on a convention of what fonts to use, what would be the writing style, potentially how long will each chapter be, etc. So there is consistency in the overall book.
The same thing is true for software development. A team needs to have some standards of how they write code? What conventions they use so the code is readability and maintainability.
Refactoring
As you make changes to anything, when you come back to those changes you will always find ways to make those changes better. This is true when you write a book or build a product, you need to continue to refactor (continuously improve) the work
Test Driven Development (TDD)
When you write any document, you would like to use tools like spell check and grammar check to ensure that what you write is corrected as you write. Test driven development is where the team can write tests first based on acceptance criteria for a needed feature. Run the tests, which fail and when they fail you write code to make them pass. TDD is a great practice not only to improve quality but also to improve design of the system
The above are some examples of the XP practices. What do you think? What can we refactor in this article?
.
Scrum, Product Management, and DevOps: Simplifying the jargon
The internet and social media are full of Agile, Scrum, Product Management, and DevOps jargon, including incorrect and misunderstood concepts. This could be problematic for a learner seeking knowledge. Without a course with Scrum Alliance, Scrum.org, or DevOps Institute, this knowledge is difficult to achieve.
The Concepts & Beyond blog is a free suite of articles and videos packaged in tiny chunks. You will learn or refine your knowledge and skills to help your team and organization be effective. When you want to take your knowledge further, we invite you to join us for our Certified ScrumMaster(CSM), Certified Scrum Product Owner (CSPO), Certified DevOps Engineering Foundations (DOEF) and Training from the Back of The Room courses across the USA and Canada.
1 Comment
All the techniques are best to be used for a better output (product)