Tag Archive for: agile

Starting a Scrum Team

/by

This blogpost will give you insights into starting a Scrum team, with a recording from the webinar and some additional information to support you with this journey.

As with Scrum in general, starting a team is easy to understand but difficult to master. I presented a webinar on this topic where I wanted to run you through the finer points of starting a team. Starting a team is not just explaining Scrum and proclaiming: “Go!”. It is a process in which the level of complexity needs to be evaluated in order to determine the right approach to move forward. Will Scrum really benefit you? Once this has been established it’s time to get into the nuts and bolts. I discussed what steps need to be taken in the first few weeks and what to expect while establishing a healthy team. 

Since we are progressively stepping into a world where remote collaboration is becoming the standard, I created the opportunity for Q&A during the webinar where we discussed some interesting questions regarding remote collaboration as well as other pain points. This can be heard in the recording of the webinar.

For those who missed the live session, don't panic! Here you can find the recording, and it is also available on YouTube.  Have a look and feel free to share with friends and colleagues. If there is anything we can help you with regarding this topic, feel free to contact us. 

 

 

We would also like to share a few links that may be of interest to you. We have a Scrum start-up package for kicking off new Scrum teams, and this link gives you some insights into this service. We would be more than happy to walk through with you how we can help support your teams. Please keep in mind that e.g. the Team Kickoff can be done every now and then with the teams, and we strongly recommend this e.g. after summer vacations or winter breaks. 

As we mentioned in the webinar, if you want to take your basic learnings to the next level, we recommend Certified Scrum Master (CSM) training. At agile42 we are currently running this training remotely, and dates can be found from the listing. 

For more on the topic of team dynamics, you can always book sessions with a coach, and if you want to learn how to support your teams with this, please have a look at the Advanced Certified Scrum Master (A-CSM) training or the Advanced Team Coaching Course (ATCC) where you can boost your own skills. These trainings give you, as an Agile Coach or Scrum Master, valuable support to help you with your teams. 

We have all kinds of support for the Agile teams, and many of the steps that I listed in the webinar are services we can provide, so please connect with us and we would be more than happy to help.

 

For more webinars and recordings, please look here! More  webinars!

 

 

To Scrum Or Not To Scrum

/by

I get many questions in my trainings, and one of the most common is when to use Scrum – usually preceded by utterances of “Scrum will never work in my team…” The wording of the question below comes from the Scrum Alliance Certified Team Coach (CTC) application. So this topic is relevant, and there is no one answer.

The Question

When might you advise a client to apply XP, Lean or a non-Agile approach to workflow instead of Scrum?

Let me answer this question by describing an actual situation. Read on for my thoughts.

The Context

I once coached a program of teams at a large corporate that had to automate a manual and laborious business process onto an off-the-shelf product. This program had been working in a waterfall manner for a year and had managed to automate a small subset of the business process.

A new CIO was employed and decided that this program needed to use Scrum because it would help with faster delivery. When I arrived this is what I found:

  • Teams had been set up, consisting mostly of contractors from different contract houses;
  • Most people had received an Agile Bootcamp training focusing on Scrum;
  • Project Managers were in-house and expected to be Scrum Masters as well;
  • Teams were supposedly dedicated, but the program manager repeatedly moved contractors in and out of the teams;
  • The deadline had already been decided by the CIO.

It became apparent that the teams were not set up for success and that the program would revert to using a waterfall process. I thought that by helping the teams focus on some of the principles of Lean without giving their way of working a label, that it would start them thinking about bottlenecks to their workflow and identify wasteful activities.

 

The Rationale Behind This Approach

Major organisational impediments which due to the nature of the organisation (size, structure, and politics) were outside of the teams’ control to resolve resulted in an interrupted value-stream, but for which they were being held accountable. Here are some of them:

  • Data sourcing – each business process was multi-layered with multiple data sources which the teams did not own nor have access to. Obtaining data required a long process with multiple approvals;
  • Environments – development, test and production environments were being built at the same time that the team needed them to do their work.

Program-level impediments:

  • Teams were not stable – people moved in and out without notice to them and the Project Managers;
  • No Scrum Masters – Project Managers were expected to also be Scrum Masters – this created a conflict of interest and anti-patterns began to emerge;
  • Teams did not own their full value stream and yet were held accountable for delivery;
  • Each business process to be automated was 1 large story because they were not easy to break down into user value items;
  • Teams consisted of more than 10 people and had 3 Product Owners.

I recommended that teams adopt Lean principles and visualise their work, in its imperfect form, and start improving where they could because:

  • The Product Owners were present and involved – there was a real effort on their part to help teams break their work down into manageable chunks taking into account the organisational impediments;
  • By visualising the workflow as it was they would start to see where all their bottlenecks were and having the teams and Product Owners focus on customer value they would begin to identify wasteful activities;
  • For me, it was also important to help teams see that their current process was not value-creating, and by regularly looking for improvements they would start to look for different ways of getting around that which was seemingly outside of their control.

There are other ways of addressing this type of problem, such as using a complexity frame and the Stacey Complexity Model. As with all things that relate to coaching, the context of the organisation and the maturity of the team are important. In order to help them become unstuck I guided them along this path and brought in the learnings of complexity later. I felt that this was, for these teams, a useful place to start.

What would you do? Please tell me below.