• Twitter
  • Facebook
  • LinkedIn
  • Youtube
  • Instagram
  • 🌐 INTERNATIONAL
  • 🇧🇷 Brazil
  • 🇫🇮 Finland
  • 🇩🇪 Germany
  • 🇮🇹 Italy
  • 🇿🇦 S. Africa
  • 🇸🇪 Sweden
  • 🇹🇷 Türkiye
  • 🇺🇸 USA
agile42
  • Consulting
        • Organization
          • Organization
          • Organizational Scan
          • Agile transformation
          • Organizational Learning
        • Leadership
          • Leadership
          • Agile Strategy Map
        • Strategic Tools
          • Agile Strategy Map
          • agile42 Leadership Assessment
        • Browse E-Learning
        • Agile Teams
          • agile42 Workshops, Coaching and Mentoring
          • Archetype Assessment
        • Agile Coaching
          • Coach the Coach & Train the Trainer Program
          • One-on-One Coaching
          • Team Coaching Framework
        • agile42 enables leaders to create a resilient organization and a sustainable change process.

          Marion Eickmann, CEO agile42

  • Team Coaching
        • agile42's Workshops, Coaching & Mentoring
          • Learn more about our tailored workshops, leadership &team coaching and individual mentoring.
  • Training
        • Your agile42 Training
          • Upcoming Training Schedule
          • What to expect from an agile42 training session
        • Leadership Training
          • Certified Agile Leadership (CAL E,O,T) / ORGANIC agility®
            • Certified Advanced Education and Validated Practice (CAL II) / ORGANIC Leadership Advanced®
        • Scrum & Kanban Training
          • Certified Scrum Master (CSM)
            • Advanced Certified Scrum Master (A-CSM)
            • Certified Scrum Professional-ScrumMaster (CSP-SM)
          • Certified Scrum Product Owner (CSPO)
            • Advanced Certified Scrum Product Owner (A-CSPO)
          • Certified Scrum Developer (CSD)
          • Kanban System Design (KMP I)
          • Kanban Systems Improvement (KMP II)
        • Coach Education
          • Advanced Team Coaching Course (ATCC)
          • ICAgile Team Facilitation Certification (ICP-ATF)
          • ICAgile Agile Coaching Certification (ICP-ACC)
          • ORGANIC agility Foundations Masterclass
        • More Training
          • OKR Certification
          • Design Sprints: The Innovation Method from Google Ventures
          • Agile at Scale
          • Agile Awareness Training
          • Agile Development Practices
        • Your Dashboard
  • e-Learning
        • Browse our eLearning Courses
          • Agile Foundations
          • Agile Leadership Foundations
          • ORGANIC agility Leadership Foundations
          • Scrum Foundations
          • Facilitating Scrum
          • Product Ownership Foundations
          • Kanban Foundations
          • Agile Coaching Foundations
        • More eLearning Courses
          • Facilitation Foundations
          • Facilitating Retrospectives
          • Team Dynamics Foundations
          • Self-Organization
          • Design Thinking Foundations
          • Navigating Conflicts
          • Agile Roles and Capabilities
          • Giving and Receiving Feedback
  • News / References
        • Blog
        • agile42’s Webinar Collection
        • Success Stories
        • Publications
          • ORGANIC agility Handbook
          • Hitchhiker's Guide to Agile Coaching
          • Agile Transition – What you need to know before starting
          • Do Better Scrum
        • Agile Information & Tools
        • Sharing experiences and learning from each other has always been a focus for agile42.
  • About Us
        • Career at agile42
        • Our Partners
        • Corporate Social Responsibility
        • agile42's Mission:

          Everyone is talented beyond their awareness and means. We help people to discover that talent and perform to that potential, achieving a higher level of satisfaction in the process. We enable them, nay encourage them to challenge the status quo, to act on their passion for learning, and to have fun while continuously improving their organization.
  • Contact us
  • Shop
  • Menu Menu
  • Organizational Change
  • Leadership
Isabel Drost

Scrumtisch with Lyssa Adkins 2011

Scrumtisch Berlin

The February Scrumtisch Berlin featured a talk by Lyssa Adkins, famously known for her publications on Coaching Agile teams. A mixture of fifty developers, scrum masters, coaches and product owner as well as one project manager followed Marion Eickmann’s invitation. Thanks for organising the event, as well as thank you to Hypoport, Berlin for providing the venue.

In her one-hour presentation she mainly focussed on two core topics: On the roles agile coaches have to fullfill as well as on the skill set needed by agile coaches. Being an agile coach (as well as being a scrum master, really), entails four very basic roles:

Being a bulldozer…

…that is getting impediments out of the way. That can be as easy (or hard) as getting appropriate equipment for your developers or teaming up with the product owner to communicate with anyone trying to break the sprint.

Being a servant leader…

…for a coach that means to work for the team, to ask the right questions and enable the team, to listen during dailies – instead of asking for additional reports: Most tools are already within the Scrum toolbox. The hard task is to identify them and use them correctly and efficiently.

Being a shepherd…

…that may be as easy as getting people to attend the dailies, or as complex as communicating common values, a common goal.

Being the guard of quality and performance…

…as a coach that means making degrading quality visible – and letting the Scrum team take the decision on how to deal with it.

However in reality each team is different, each sprint is different. So coaching really is similar to bing the river guide: Each trip is different. It is your task to make the team succeed and adapt to differing situations. To get to team to high performance – over and over again.

When talking about coaching what people need is a very specific skill set:

  • To become a successful agile coach it helps to have coaching skills to be able to understand the client, to see their impediments and help the team become better by listening and asking powerful questions.
  • Be a facilitator who organises sessions, meetings, conversations and may mediate in meetings.
  • Have business domain expertise – that is to know process designs, figure out a companies strategy options.
  • Be a great teacher to help people understand the basic concepts. That entails knowledge on course design, most likely design of exercises.
  • Have mentoring skills to guide a team in the process.
  • Know about lean and agile processes and stay up to date.
  • Have the technical skills on what makes development successful, know the extreme programming techniques to help team excel.
  • Have transformational skills – that is be familiar with change management, transformation leadership, knowing how to change organisations.

However being a coach remember that people are influenced not only by what you teach – but mostly by what you do. Most of what being a good coach means is invisible to the uninitiated outsider. It’s about living the process you teach, staying true to the principles you want others to implement.

To get there it helps to get inspired, to talk with others in local meetups (just as with any coding practice: Try to find a common forum to exchange ideas and get fresh input). It may help to keep a value journal – not only to track your accomplishments and be able to prove them to higher management, but also to track where to improve yourself.

The talk provided several interesting starting points for exploring further. However with an added exercise sixty minutes covered only the very basic ideas. Especially for the skill sets needed to successfully coach teams it would be very interesting to learn more on what books to read or what courses to attend to learn more on each topic. Ultimately not only agile coaches benefit from being great teachers, mentors or facilitators.

February 18, 2011/by Isabel Drost
Marion Eickmann

Scrumtisch June – Agile Teams and Other Topics…

Scrumtisch Berlin

Neither football and nor the heat could not keep us away from the Scrumtisch on Tuesday. More than 20 people exchanged experience and knowledge about the following topics and have been listening to Bent who was talking about how to create a real team.

Topics of the open discussion:

What to do if Continuous Integration/Maintenance Bug fixing eats up more than 50% of capacity?

  • More support from the team developing
  • How to prioritize Bugs vs. User Stories?
  • Check-ins more often and smaller chunks
  • Tools pre-building or green-checking control
  • Distributed builds with fast running tests
  • Evaluate rate of technical debt reduction and decide for either a stabilization period or dedicated maintenance

One team on two Sprints?

  • Focus on one project at a time
  • Stream all stories into one unique backlog
  • Remove team members from the “old” team and start building the “new”
  • Prioritization should be unique among all stories
  • Avoid task switching and multitasking

Role in a Development Team (Rotation, knowledge share)?

  • Skill mapping an team level and set Key Performance Indicators (KPIs) for evolution
  • Pair programming

High performance teams

Thanks again Bent, for your interesting and useful talk. :-)

We also have the the slides of the talk available for download, and recommend this article on coaching Scrum Teams for further reading.

See you soon at the next Scrumtisch

July 1, 2010/by Marion Eickmann
Marion Eickmann

Coaching self-organising teams

Scrumtisch Berlin

As usual we started collecting topics (timeboxed to five minutes). The list was rather short, however it contained several interesting pieces:

  • (6 votes) Management buy-in
  • (6+ votes) CSP – Certified Scrum Professional – what changes compared to the practitioner?
  • (4 votes) Roles of Management in Scrum – how do they change?
  • (13 votes) Coaching self-organising teams – team buy in.

Coaching self-organising teams – Team buy-in

As prioritised by the participants the first topic discussed was on coaching self organising teams – with a heavy focus on team buy-in. The problem described dealt with transforming water fall teams that are used to receiving their work items into self organising teams that voluntarily accept responsibility for the whole project instead of just their own little work package.

The definition of self organising here really is about teams, that have no (and need no) dedicated team leader. On the contrary: leadership is automatically transferred to the person who – based on his skills and experiences – is best suited for the user story that is being implemented at any given time.

The problem the question targets is about teams, that really are not self organising, where developers do not take responsibility for the whole project, but just for their little pieces: They have their gardens – with fences around that protect them from others but also protect themselves from looking into other pieces of the project. Even worse – they tend to take these fences with them as soon as work items change.

Several ways to mitigate the problem were discussed:

  • Teams should work in a collaborative environment, should have clear tasks and priorities, whould get some pressure from the outside to get things done.
  • Some teams need to learn what working in a team – together – really means. It may sound trivial, but what about solving problems together: Spending one day climbing hills?
  • Committments should not happen on tasks (which by definition are well defined and small) but rather on Features/ user stories. Task breakdown should happen after the committment.
  • There are patterns to break user stories that are too large into multiple user stories.
  • Teams need to be coached – not only the scrum master should get education, but the complete team. There are people interested in management that tend to read up on the topic after working hours – however these are rather rare…
  • Teams must be empowered – they must be responsible for the whole project and for the user stories they commit to. In return they must get what the need to get their tasks done.
  • Newly formed teams inexperienced with Scrum have to get the chance to make mistakes – to fail – and to learn from that.

A great way to explain Scrum really is as a two-fold process: First half is about getting a product done, reviewing quality by the end of each sprint during the review. Second half is about improving the process to get the product done. Meeting to review the process quality is called retrospective.

Management buy-in

The second topic discussed was on the role of management in scrum – and how to convince management of Scrum. To some extend, Scrum means loosing power and control for management. Instead of micro-manageing people it’s suddenly about communicating your vision and scope. To get there, it helps to view lean management as the result of a long transformation:

  • First there is hierarchical management – with the manager at the top and employees underneath.
  • Second there is shared management – with the manager sitting between his employees enabling communication.
  • Third there is collaborative management – here the manager really is part of the team.
  • Fourth comes empowering management – this time the manager is only responsible for defining goals.
  • Last but not least there is lean management – where managers are merely coordinating and communicating the vision of a project.

To establish a more agile management form, there are several tasks to keep in mind: First and foremost, do talk to each other. Explain your manager what you are doing and why you are working in pairs, for instance. Being a manager, do not be afraid to ask questions – understanding what your developers do, helps you trust their work. Scrum is established, however there needs to be a clear communication of what managers loose – and what they win instead.

Scaling can only be done via delegation – however people need to learn how to delegate tasks. In technology we are used to learning new stuff every few years. In management this improvement cycle is not yet very common. However especially in IT it should be.

Sellling Scrum to a customer

Being able to sell Scrum to customers is yet another problem: You need good marketing to sell Scrum to your customers. Money for nothing change for free is a nice to read on formulating agile contracts. Keep in mind, that the only way to really win all benefits is by doing all of Scrum – cherry picking may work to some extend, however you won’t get the full benefit from it. In most cases it works worse than traditionally managed projects.

Finally…

After two very interesting and lively discussions moderated by Andrea Tomasini, agile42, we finally had pizza, pasta and drinks – taking some of the topics offline.

Looking forward to seeing you in F-Hain for the next Scrum User Group Berlin Scrumtisch in April.

Last but not least I would like to thank Isabell for providing this nice summary, and if anybody would like to know more about Apache… Isabel’s Blog is the right place to go :-)

March 31, 2010/by Marion Eickmann
Marion Eickmann

Interesting Scrumtisch in November – Some content

Scrumtisch Berlin

This evening agile42 organised another successful Scrumtisch: Usually we either meet for timeboxed discussions on Scrum and agile development questions or a speaker is invited to present his favourite Scrum or Lean or Agile topic.

Today Markus Frick gave a presentation of how Scrum was introduced at SAP, a German software company. They started implementing Scrum in a “small” team of about 60 people, organised in about six to seven teams. The idea was to get people together who are already sort of familiar with agile technologies and let them evaluate what works in the companies context at what doesn’t. The conversion started with trainings, teams were organised by features as opposed to components. The main goal was to get people to learn Scrum and then spread the idea across the whole company.

Soon upper management were fascinated by the methodology – not shortly after that the goal was reset to converting 2500 employees working at four different locations (Bangalore, Berlin, Waldorf and Sofia/France) on diverse topics ranging from developers to managers to agile methods. The question thus turned from scaling Scrum to quickly scaling the conversion process: Where do we get enough trainers? Where does Scrum expertise come from? How should communication be organised? How do we adapt our sales and governance processes?

The way to do this chosen back then was to use Scrum itself for the conversion process. That is to introduce teams for training and conversion and let them work according to a backlog. Also managers were set up to participate by organising work according to a backlog containing management tasks. This first led to quite some confusion: Conversion does take time and working according to sprint backlogs makes it pretty much obvious how much time it actually takes and how much time people really spent on these tasks. On the other hand, the whole process was made very transparent for everyone – and open for participation.

The process started about two years ago – it has not finished to date and processes continue to evolve, get improved and refined as people go along. A very rough estimation was that it might take another three years to get to a stable, clean state. However most – if not all – problems were not caused by Scrum. They were made visible and trackable by Scrum.

The main take-home messages were that Scrum does bring improvement:

  • It makes goals transparent and communicates clearly the current state.
  • You get a short feedback cycle so people actually see where problems are.
  • It inherently allows for reflection and analysis of problems.
  • As introduced here it also made the work of management people transparent by making backlog and velocity of managers accessible by everyone.
  • Internal training helped to get feedback from teams who are already practicing what is introduced.

Among the people who were very skeptical there usually were quite a few people from middle management. Uncertain about how future development should work they usually feared a loss in influence. Most positive feedback came from developers themselves: After explaining what Scrum is all about, which includes shore release cycles and fast feedback, most developers that were in the teams already for quite some time reacted by stating that this basically resembled development “in the good old days” with a bit of development process added on top.

If you are interested in hearing more stories on how Scrum is or was introduced in companies of various sizes, I would like to recommend visiting the German Scrum Day in Düsseldorf. The talk by Thilo Fromm gives a nice overview of how a transition from traditional Waterfall to Scrum can look like. And agile42 Andrea Tomasini will talk about the Scrum implementation in distributed teams at be2 ltd.

November 27, 2009/by Marion Eickmann
Marion Eickmann

Review Scrumtisch 16th June

Scrumtisch Berlin
Hi everybody, I think you agree, that the presentation of Philippe Kuchten yesterday was great, very informative and interesting. Here are some pictures and the link to the presentation from the Scrumtisch yesterday.
20 Attendees at the Scrumtisch Berlin in June
Philippe Kruchten was talking about: What color has your backlog
Interesting discussions and great food and drinks
Philippe held the presentation at the Orlando Scrum Gathering too. Here you can download the presentation
Comments are very welcome
June 17, 2009/by Marion Eickmann
Marion Eickmann

How we organize the Scrumtisch

Scrumtisch Berlin
Some information on what you can expect when visiting the Berlin Scrumtisch.
  1. Finding the topics
    Of course, we appreciate proposals upfront for the upcoming Scrumtisch, but mostly people are busy and therefore we collect wishes and questions at the beginning of the event. We write these questions on the “wall” and after we prioritize them. We can make use of an electrostatic whiteboard, and a projector, so if you want to prepare something, you are really welcome, just post your idea into the Scrumtisch website
  2. Timeboxed discussion
    The 2 highest prioritized “Topics” will be discussed. The others are ending up in a backlog for the next Scrumtisch. We focus on each of the 2 topics for 30 min. One of the group is moderating the discussion and takes notes, ideas and hints on the wall. Someone should also take care of writing things down and posting them on the Blog, but unfortunately not always happen… we can improve this :-)
  3. Open talks and good food
    After the “official” part of the Scrumtisch we are just sitting together, talking in small groups about the topics or other issues, and enjoying very nice italian food & drinks.

So everybody is welcome to join the scrumtisch, share experiences and lear new things.

Keep it lean and agile :-)

March 9, 2009/by Marion Eickmann

About agile42

agile42 enables leaders and their teams to create a resilient organization and a sustainable change process. We equip them with the tools they need daily to grow the business and foster the right organizational culture.

Recent Posts

  • Webinar | The Top Challenges Facing Modern Leaders 
  • Mastering Soft Skills for Effective Work: Your Path to Professional Excellence
  • How To Become A Scrum Master
  • How to Become a Product Owner
  • Navigating the Storm: Overcoming Teamwork Challenges Together

Instagram

 
 
 
Follow on Instagram

Coaching Book

The Hitchhiker’s Guide to Agile Coaching

Leadership Book

About

agile42 enables leaders and their teams to create a resilient organization and a sustainable change process. We equip them with the tools they need daily to grow the business and foster the right organizational culture.

HQ

agile42 Consulting GmbH
Grünberger Str. 54
10245 Berlin, Germany
Phone: +49 30 200 53958
Email: [email protected]

WORLDWIDE

🌐 International

🇫🇮 Finland

🇩🇪 Germany

🇮🇹 Italy

🇺🇸 North America

🇿🇦 South Africa

🇸🇪 Sweden

🇹🇷 Türkiye

🇧🇷 Brazil

Newsletter

Read more information about our privacy practices. By clicking to subscribe, you agree that we may process your information in accordance with these terms.
© agile42 2023. All rights reserved. The agile42 logo and name are trademarks of agile42 GmbH.
  • Twitter
  • Facebook
  • LinkedIn
  • Youtube
  • Instagram
  • Contact
  • Career at agile42
  • Legal & Privacy
  • Social Responsibility
Scroll to top