My former colleague Eva Kisonova and I presented at the Software Quality Days in Vienna about our work towards an agile systems development methodology (agileSEM) for Siemens CEE. This work aimed at supporting the organization to make sense of the new development approach and to support teams that wanted to become agile and feared restrictions by all the Siemens regulations. We are confident that our group of involved people provided a helpful guideline for the teams on how to apply agile principle, values and practices in their daily work. Feedback by the teams show that they used and valued agileSEM. Even CMMI assessors think it helps to increase quality and company learning though some assessors believe that more processes need to be documented.
Registered people can download our presentation. I like to thank all interested participants for their questions.
Katharina Fritz (Agfa Healthcare) and I will present at the London Scrum Gathering. The title of our presentation is “How to Evolve From Specialized Individuals to a Co-Working Team: An Experience Report”. The following is a part of our submission:
During our Scrum transition we realized that without major changes we might not be able to finish our stories according to their priority and that work could be left undone when specialists drop out. We provide insights on how a group of people changed from specialized individuals to a collaborating team. We present initial worries, like: Does everyone have to know everything? We introduce a coaching system, its values, principles and practices. We show how the team charter played an important role and how the team evolved it. The team felt that motivation, collaboration and quality increased.
It can work to get away from specialists behaviour to team collaboration. We offer one approach that worked for us to overcome specialization towards collaboration. The audience can take away several ideas on how to approach one aspect of a transition to Scrum.
We look forward to meet you in London.
I’m now at the airport in SLC after a week packed with information and new people. First and foremost, I’d like to thank all the organizers for their support. It was fantastic. I hope the final glitch will be resolved soon and all material will be available for download.
Marc Bless and I run a workshop on Fear-Driven Impediments (handouts). The participants were great. They discussed a lot of issues around fear. We had two comments on improving the workshop: have a role play and give us more input on how to deal with fear.
I enjoyed talking to a lot of people and I also attended some sessions. The program was packed and it was difficult to decide where to go to. I liked the following sessions:
Abby Fichtner’s sessions was clearly a highlight as it challenged so many assumptions on product development. In the context of Lean Startups Agile development needs to go a few steps further. For example, while most teams struggle with the “Definition of Done” as something being developed or deployed, for Lean Startups “Done” means that ideas have been validated by customers. Learning is key, not working software.
Mary Poppendieck’s stated in her session that user stories are already design decisions. It is more important to understand the problem a customer wants to solve. Also, Mary clarified that the Product Owner in Scum projects carries multiple roles depending on the complexity of the project. The PO can be a Software Designer, Systems Architect, Business Analyst, and much more. My conclusion was, that a PO needs to work in a team of people.
The keynotes by Barbara Fredrickson on Why Care about Positive Emotions? and by Linda Rising on The Power of an Agile Mindset were both informative and inspiring.
It was also interesting to see and meet many of the signatories of the Agile Manifesto and to hear some of the background stories.
There were many talks, tutorials and workshop on coaching and fewer on the technical side of the Agile adoptions. I’m happy to see that Functional Programming becomes a topic for Agilists as I have a background in Haskell.
I look forward to apply some of the learnings in my work, to keep in touch with some of the participants and to meet them again, either next year at Agile2012, the Scrum Gathering in London October 2011, the XP2012 in Malmö or even at the XP2013 in Vienna.
Last weekend I had a great time at the Agile Coach Camp Germany 2011 in Rückersbach. I met so many great people, all interested in improving the way we build software. The ACCDE is an unconference which basically means that the program is created by the participants at the conference.
I facilitated a session on the role of agile coaches and how to handle the different roles we often have. The outcome of the session is:
The different roles of an Agile Coach:
- Trainer – say how it works, has experience
- Mentoring – a mix of being a trainer and coach
- Consultant – analyses issues and implements solutions
- Facilitator – supports the team in different meetings
- Coach – does not have to have domain knowledge, is a guide for a thinking process
During the discussion we identified the following ways for an Agile Coach of handling the different roles when working with teams:
- ask the coachee which role (s)he expects
- design alliance: Ask: What do you expect from me? Tell: What you can do… Do this with sponsors, management, teams…
- remember: every case is different
- establish coaching contracts
- Do you want my solution or do you want to find your solution?
- when giving a solutions, then ask “How do you feel about that? What would you do next?”
- Prepare selling – ask what advice would help?
- provide options to choose from
- client/coachee needs to take ownership of solution
- form an attitude of not knowing
- exploring side effects of knowing/not knowing “what would be/happen…?”
- I advice you to try…experiment => safe-fail environment (acceptance of my fail)
- safe-fail environment to be created by teams, coaches…
- coaching-like trainings (i.e. apply coaching practices in training)
- client need to recognize own problems and what his/her acceptance criteria are for a solution
- suppose we are doing something useful here, what difference would we see? What would you do differently afterwards? – ATDC “Acceptance Test Driven Coaching”
- demystify “coaching” – show you can make mistakes and learn
I’m sure there are many more ways to ensure you wear the right hat in the right situation and that the team/coachee knows which hat you are wearing. Also be aware that the coachee doesn’t give you a hat without you knowing. I’d like to thank everyone that participated in this session.
I also attended sessions on “The four evil root causes: Ignorance, Fear, Indolence, Apathy” facilitated by Marc Löffler and “Systemic Structural Constellations” facilitated by Klaus Schenck and Christine Neidhardt. Also I had great talks with participants in-between sessions and butterflied around otherwise.
Marko Seikola (@mseikola) and Kjell Lauren (@klauren69) provide a great summary of most of the session on AgileInc On-The-Road.
My colleague Marc Bless and I will be leading a workshop at Agile2011 named “Fear Driven Impediments”.
In many cases fear is a reason for impediments of an agile team and can cause many effects: resistance to organizational change, procrastination of decisions, inability to surface the real issues in retrospectives. To successfully remove such impediments, the fears of all involved individuals must be understood. If fear is a reason to fail, it should be dealt with as fast as possible.
This workshop arose out of an Open Space session at XP2010 and was further refined at the XP Days Germany 2010.
Marc Bless and I initiated a session on “Overcoming fear at the workplace” during the Open Space at XP2010. I’d like to thank everyone for participating and contributing to make it such a fun and inspiring moment of the conference.
While being in Boston, I attended the open floor session of the SD Best Practice 2006 conference. I will consolidate my findings from there and publish some of it here too. I was impressed by the many talks and tools for Agile Software development methods.
Next week I will be on a course – learning about the standard development method at my company. This is a classical waterfall model. Since I have been using the Agile Method SCRUM in my last project this will be an interesting contrast and surely a source for discussions.