Posts

Passing the PSM 1 assessment could be considered an indicator that you understand the Scrum theory and the principles that underpin Scrum. I always tell students in my PSM class, that my intention is not to make them pass PSM 1 but understand Scrum theory and principles.

There are a number of exercises that Professional Scrum Trainers invite students to partake in the course of the PSM 1 class; these exercises have been designed on practical experiences of Professional Scrum Masters and these exercises create a solid foundation for you as you commence your Scrum Master career.

You have just passed your PSM 1 assessment; however you would like to get some working experience as a Scrum Master. In my time as a Professional Scrum Trainer with scrum.org, the people that share this concern with me fall in 2 categories:

• People that have self studied for the PSM and achieved the 85% score for the PSM1 assessment
• People that attended a Professional Scrum Master class and achieved the 85% for the PSM1 assessment

You must realise and accept that passing the PSM 1 assessment is not the end of the learning process; the journey to being an experienced Professional Scrum Master is a life long learning experience. There are a number of complimentary practices would help you support any Scrum team, some examples include Estimation, Facilitation Techniques e.g. Liberating Structures, Velocity, Product Backlog Refinement and many more. Use the scrum.org forums and carefully curate content on Youtube, preferably youtube content from Professional Scrum Trainers.

In the 2020 version of the Scrum Guide, the Developers as one of the accountabilities in Scrum is defined as set of people that are committed to creating any aspect of a usable increment each Sprint.

In the same version of the Scrum Guide, it is mentioned that the Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

A number of people have asked me if Usable, Valuable and Useful could be used interchangeably within the context of Scrum and this is my attempt to document my understanding.

The process of ideating and developing products (including software products) falls within the domain of Complex Systems. A complex system is a dynamic network of interactions, where the behaviour of the system as a whole may not be predictable based on the behaviour of its component. A model such as the Cynefin Framework which was developed by David Snowden has helped with our understanding of complexity and our approach to addressing complex real world problems.

Models are useful tools that helps understand our self and the growth process. Learning is a critical part of the growth process and I have always referred to the Shu-Ha-Ri concept as a model that help me with mapping out where i was along the process. It is a a very simple but POWERFUL concept and i am hope you find this useful as much as I have.

Shu:

In this phase, the apprentice follow the rules that have been taught and rarely deviate from the rules. The apprentice learns by repetition of the same techniques that has been learnt, many times over until muscle memory is built.

A very long time ago, I was coaching a Scrum team where a team member was on an hourly contract and was regularly billing 70-80hrs a week. Among many other ideas that I discussed with client, I advised my client was to transition this consultant away from an hourly contract to a full time with a full-time (40hours a week) contract. With this new arrangement, my client can recruit two full time consultants instead of one person at 70-80hrs week.

I have always been one of those people that believed one of the major factors for succeeding with Agile ways of work is physically co-located teams. As far back as 2007, I remember the joys of walking into an open plan office bustling with activity, and colourful post-it notes on white boards within the office. Being the self confessed Agile Evangelist that I was, I would lobby for co-location within the work place as i believed it complimented collaboration; we just preferred the business and technology teams sat next to each other. 

It is surprising that many “agile” teams still have a User acceptance testing phase within their software development lifecycle; if this doesn’t surprise you, then it surprises me. To be clear, I refer to an “agile” team as a team that has adopted one of the Agile methodologies i.e. Scrum, Kanban, SAFE e.t.c. as their chosen methodology to build their product. One of the agile manifestos reads “Customer Collaboration over Contract negotiation” and this implies that we are encouraged to Collaborate with the Customer while building the product. Our customer should include users of the products, Vendors that interface with the product and Product Sponsors; and there could be more.

Fix us Quick.

The process of transforming an organisation to be Agile is a one that is ladden with continous learning and not a quick fix as some might make it seem. Organisations would often employ an Agile Coach for 3months to 1 year hoping that at the end of this period, the organisation would have completed their transformation journey. A great Agile Coach will always inform you that even after the engagement ends, the journey of Agile Transformation has not ended. Most of these coaching engagements are usually attempts to get the client to adopt new tools and practices but experience has shown that the best Agile Coach help the organisation on its journey to change it’s Agility Mindset.

Usually when I join an organisation or team to help identify challenges with current processes and help the teams fix their processes, I would usually look for bottlenecks within the organisation. Once identified, bottlenecks are usually not difficult to eliminate compared to the effort that is required to ensure that behaviours that have introduced the bottlenecks are unlearnt.

A bottleneck can be described as a process within a chain of processes that reduces the overall capacity of the entire system due to the limitation of that single process. Some examples of bottlenecks in typical software development team include: