Agile

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:

• Applying the lean startup model to the Enterprise: Jez Humble
• Making the Entire Organization Agile: Stephen Denning
• Narrative Coaching: Scott Dunn
• Design Thinking: Mary Poppendieck
• Continuous Delivery: Jez Humble
• Tests as a Means of Abstraction: Brian Marick, Michael Feathers
• Lean Startup: How Development Looks Different When You’re Changing the World: Abby Fichtner

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.

Am Montag, dem 18.7.2011, werde ich beim pma quarterly einen Impulsvortrag halten. Dieser basiert im Wesentlichen auf unserer Veröffentlichung Is There Hope for a Certified Project Manager in an Agile World? – Inspecting Behavioural Competences of Project Managers and ScrumMasters im GPM-Magazin PMaktuell, Ausgabe 2/2011. Darin argumentieren wir, dass einige der Verhaltensweisen, wie sie in der ICB 3.0 für Projektmanager beschrieben sind, hilfreich für ScrumMaster sein können und andere nicht. Als hilfreich sehen wir z.B. das Verhalten in Krisen an und als hinderlich z.B. das empfohlene Führungsverhalten. Dieser Impulsvortrag leitet dann eine hoffentlich anregende Podiumsdiskussion ein.

Die Veranstaltung ist ausgebucht. Ich bin schon sehr neugierig, wie die Verteilung der Teilnehmer ist und welche Fragen den Teilnehmern am meisten am Herzen liegen.

What is agile software development?

Agile software development is a set of values, principles and practices. It is based on iterative and incremental development, where requirements and solutions evolve through collaboration between customers, stakeholders and self-organizing, cross-functional teams.

The agile manifesto

In 2001 seventeen people met to discuss the similarities of their approaches to successful software development. The result was the agile manifesto. It states four values and twelve principles that capture the essence of what is now known as agile software development. Of course, you can read that in detail there. However, let me re-phrase the key agile values here:

• You need Individuals and interactions to get value on processes and tools
• Working software is more valuable than writing comprehensive documentation
• When having intense collaboration with the customer you do not need to negotiate heavy contracts
• You should have a plan, but your processes shall enable you to be responsive to change and adapt accordingly

Why might you want your organization to be agile?

Your customers aren’t delighted? Costs overrun? The schedule isn’t met? The software developed isn’t really what’s needed or it’s too late? Know-how isn’t spread across the team or the organization? There can be many reasons for this. Agile methods can help to reduce these risks.

Agile software development is a means towards delighting your customers. It aims at building business success through frequent and sustainable delivery of value to your customers, your stakeholders and your organization. This can be achieved by delivering software your customer really needs and by building an organization that can deliver high quality regularly. Through retrospectives the teams find ways to enhance their capabilities and to achieve sustainable pace. An engaged customer plays a vital part in this endeavour, too. The customer can help the teams to focus on the most valuable outcome and provide regular feedback on the progress and the changes needed. In agile projects, the customer will receive working software early. In some environments this means that the customer can use the software to gain some return of investment even earlier than in traditional projects. All this is designed to increase customer satisfaction.

As project manager and project management consultant at Siemens AG Austria I experienced hands-on the advantages of this approach. Customers and line managers were satisfied and the team members stated that they wouldn’t want to work in another way again. I gained similar experiences in other organizations that I worked for since.

What can I do for you?

Agile software development implies a new philosophy in project management. All team members, stakeholders and customers must know the rules of success in agile development and share the mindset necessary to be able to work like this.

Therefore I offer the following services:

• Consulting to establish agile organisations and teams, choosing the best methods in the respective environment and doing all the things necessary to start
• Coaching and consulting for teams, stakeholders and customers already working and having troubles
• Coaching for individuals and teams during a longer period of the project
• Training in agile techniques and practices

If you have large projects, where you need more than one consultant, I also act as part of a network of agile coaches with whom I work together regularly.

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.

Whilst reading this, you may be asking yourself whether I am the right person to tackle your tasks and challenges. I will be glad to discuss this with you in a personal conversation, but for now, please allow me to present the following thoughts.

As a PhD of computer science, I have learned that the goal of developments is the implementation of working software in application systems. However, who lets us know if it’s really working? Exactly, the end-user! Only through their feedback can we tell if the goal has been successfully reached. I’ve been reflecting on this from an early age, since my father started asking me: “How can you tell that it’s right?”

Furthermore, through my work for and with international corporations such as Siemens, Deutsche Telekom, Nokia and Agfa, I have learned how important it is for the development teams to continue working with each other after completion of a particular project. This is often not easy, since each team is a conglomerate of differing characters, social backgrounds and individual development potential. A team leader can identify and utilise these differences and show the team how to operate. Implemented correctly, this method alone already produces satisfactory results.

As an Agile Coach, I take it a step further: I’m not satisfied by simply showing people what agile is; I guide the team leaders towards becoming agile themselves. I support and give feedback; we try different things out, and uncover hidden opportunities together. Quite often this leads to team members changing the way they act and think. They cast off old habits and change behaviour patterns.

This method of finding solutions correlates with my knowledge as a Systemic Coach. As such, I see coaching as a solution- and resource orientated process support. You, the customer, are experts with regard to your business and issues. I, the coach, am an expert in co-developing different approaches to possible resolutions with you. In this capacity, I support my customers in shaping (and creating) tailor-made results.

I have had (and continue to have) the privilege of teaching a lot of students, and am only satisfied when I have found a way of showing them how to reach even better educational results independently. Therefore my first objective is to guide my customer or the team leader on how to become an agile personality and bring together an agile team, so that they can utilise their full potential for the good of the company.

As part of the approach we also begin working on the respective team assignment at hand. Despite the development of agile skills taking time, the results are demonstrably better. The initial extra time spent quickly pays-off. The market shows that agile companies can establish themselves more successfully.

I look forward to showing you that it will be to your advantage once I apply my broad expertise to your particular demands.

Dr. Ralph Miarka

In my opinion, one of the most influencing factors in motivating people is to show gratitude. Unfortunately, I often see that this is hardly applied. Often we hear what we could do better instead of an honest “thank you” for what has been achieved.

During my coaching intensive training at the E.S.B.A. – the European Systemic Business Academy - I learned the following appreciation exercise, which I like to call “a shower of appreciation”.

The exercise is done in triads. People need to have a good understanding of each other, best by having worked together. The three participants sit together, two facing each other and the third person sits in a 90 degree angle to the conversation, looking away (something like this: >^<). The two people then talk about this third person for some time (I tried 1min as well as 3min rounds). There are two rules: you are only allowed to say positive things and nothing that was said can be reduced in meaning by anything said afterwards. This is performed three times so that each person sits in the shower seat.

When I participated in this, it felt great. I have run this exercise with a group of 42 people and a heard about an experience that this was used with a team of 12 people. Every time, the participants reported that they felt great, appreciated and this gives a huge boost to motivation and trust.

I hope you can use this exercise too. I would be happy to hear from you.

Today I read the post by Mark Levison on story slicing. It made me think of an issue I have been carrying around for a while – how to explain to ProductOwners what it means to slice features in a meaningful way. The standard answer is that each slice needs to provide business value. But what is that? I work mostly in large companies that have long release cycles (three month to one year). Sometimes the customer wishes so, sometimes to have meaningful releases it takes time to develop and test the software thoroughly. Business value is in features that are bigger than one sprint.

So, what can we gain in one sprint? Joseph Pelrine answers this in his ScrumMaster classes: information. So the V in INVEST, i.e. the value of a user story, is to provide us with information and this information can then be used to inspect and adapt our efforts towards reaching the desired business value.

We work on two levels of learning. On the one hand, we gain meaningful information, when the customer can inspect the result and tell development whether it is what (s)he intended. On the other hand, we want to gain information on our process, tools, and interaction. Thus we need to fully integrate the solution, test and document it. (Hm, maybe the “I” can also stand for “integrateable”?)

I hope this to be a helpful insight as it might offer Product Owners a new view on how to slice features into user stories that are fit for one sprint.

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.

Last week I conducted a two day in-house agile/Scrum training in Slovakia.

I enjoyed it very much apart from the few people that clearly didn’t want to be there and thus didn’t make an effort to contribute. One agile principle is to build your project around motivated individuals and trust them to get the job done. It is frustrating to realize that the project might fail because of the selection of people.

Contrary there was also a rather motivated group present. They started their agile project three weeks ago and had lots of good and detailed questions.

I also learnt a lot again. I need to extend the time for Q&A from 30 to 60 minutes although I answered questions along the way anyway. I think I will shorted the “User Stories” part. Frankly, I think it is not so important to have user stories if the requirements are given in another way. It is important to know the who needs what and why though and to have clear acceptance criteria. This can all be mentioned when talking about the product backlog anyway. I also need to improve the introductions to the Scrum form Hell and The Agile Hour exercise.