Tactics for maintaining quality under pressure

Yesterday, I had great time joining some of my friends at Endava and their guests for the presentation of “Tactics for maintaining quality under pressure” by Eoin Woods (CTO at Endava).
Liked Eion’s straightforward style and fast-speed-talk. The presented tactics are somewhat common-sense, and at the same time critical for successful delivery, so I decided to drop my 2 cents on each of those.

1. Understand the context
Context is the king... I would stress on understanding the business value and the underlying business needs and pain-points behind the technical requirements. Those needs could probably be satisfied in innovative and creative way, and in order to inspire those we need to present to the techies why do we have such requirements and what in the end we try to achieve ...and again: WHY?

2. Make implications clear
Any workarounds and cutting-edges approach costs should be clearly communicated. If in the future we need to refactor or even redesign and redevelop entirely services just because of today’s decisions – those should be clearly explained and agreed on with the product folks on client’s side. Those are even worse if the consequences are on architecture’s side.

3. Track and cost technical debt
Another great tactic… with my teams we regularly follow. Putting the technical debt as backlog items and roughly estimating them helps us backing up decisions to force any of the most critical items, prioritized and tackled in future iterations.

4. Make quality visible
Another important one. I would say even critical for iteration review. Visibility over functional and performance tests increases trust and shows everybody that quality matters!

5. Simplify
Simplicity is a favorite principle of mine. Less complexity often leads to better quality and maintainability. 

6. Automate everything
Another obvious one; I would only disagree that it depends on the project size and context. Sometimes the overhead could be too much, trying to automate everything possible. Also, we should not forget automation requires maintenance too. Do we want to spend a lot of our team’s time and effort in maintaining automation? Balance is the key.

7. Enforce valuable process, discard the rest
Processes, just for the sake of doing them, should be discarded. Nevertheless, I work mostly on creating and inspiring the healthy culture of delivery, respect and learning within everybody in the company. As we all are aware – 'healthy culture will handle broken processes'. Yes, it is more difficult and time-consuming to influence and change the company's culture, but in the end it’s more beneficial for everyone too.

--
Kudos to Eion for inspiring my thoughts on the topic.

'Agile thinking' training

It's been an amazing year. Myself and Bogi prepared, polished and delivered a great number of talks, trainings and events @EPAM. We ran sessions on Agile, Scrum, Public speaking, Creative thinking, Soft skills and more. Over December we ran a couple of sessions of the revamped 'Agile thinking' training. A group of young and motivated enthusiasts practiced their skills and learned about: setting up vision & goals, understanding the context, delivering in iterations, getting feedback, teams collaboration, reducing waste, kaizen, and Scrum. It was great, we had a lot of fun and enjoyed every minute of talking and doing with the awesome trainees.

Let me share the experience and spirit, using a couple of photos (courtesy of EPAM Bulgaria)

Agile and Scrum training for the future generation

Renovated building, infrastructure, completely refurnished and equipped with modern hardware. Welcome to the new Professional High School for Computer Programming and Innovations in Burgas.

Myself and Smilen were commissioned to deliver Agile and Scrum training for 120 fresh students.

It was intensive, but engaging and we all had a lot of fun. We presented very little, mainly about Scrum values and how we use them @EPAM and our teams. The main event was a workshop to encourage the students to use the Scrum framework and produce real value and products in a couple of short sprints.

Let the pictures speak

Interview with Simo @EPAM

 (image by EPAM Bulgaria)

Recently EPAM’s InfoPortal published my interview, related to the most recent training ‘Mastering ScrumMastering’, and hopefully the insights would be useful for all of you who wish to develop as trainers.

--
Simeon Kisyov has successfully delivered several training sessions on Scrum in Sofia. Today, he shares the ‘backstage’ of a trainer’s activity, the secrets to delivering good training, and plans for the future.

EPAM: What was the reason behind your wish to contribute as a trainer?
Simeon: That’s what I do. I love conducting training sessions and delivering talks, sharing experience and inventing amazing games and challenges so that participants can learn and grow quickly while having fun. Supporting people to get out of their comfort zone feels great.

EPAM: What training have you already conducted?
Simeon: I’ve delivered ‘Agile and Scrum Foundations,’ ‘Mastering ScrumMastering’ in a series of trainings, a couple of talks, e.g. ‘Self-organizing teams’, ‘Empower your decisions,’ and a lot of other 'Agile training' events. Some of those we developed together with Bogoy Bogdanov.

EPAM: What was the most challenging thing for you while preparing training sessions at EPAM?
Simeon: Innovation is always a challenge. I ask myself, ‘If I am to attend the training, what would keep me interested in it, what would be the ‘wow’ moments to keep me engaged and hungry for more, what would be useful to practice, without being boring.’ Based on these, I develop games, talks, presentations, and practice sessions, keeping in mind the mantra: ‘Engage with the audience to influence a change.’

EPAM: What to your mind is the most interesting during your training sessions?
Simeon: Most of the games were fun. Probably the ‘out of the box thinking’ game ‘Still picture’ when we all used our bodies to create and evolve pictures. Very creative and cool scenes we got there.

EPAM: What changes have happened in your daily activities/personality after training conducting?
Simeon: Surprisingly, I had to cover the Product Owner role in the team for some time. (laughing)

EPAM: Your training has very good feedback from participants. What’s your personal secret for good training? How do you create a high-quality educational event?
Simeon: Innovation, a lot of practice and always sticking to ‘Deliver value in an easy-to-understand/practice and interesting way.’ The formula is useful + interesting(fun) = valuable.

EPAM: What inspires you for daily work and conducting trainings?
Simeon: I love sharing knowledge and experience and helping others growing.

EPAM: What would you recommend to trainers preparing their first training event?
Simeon: Delivery is everything (not materials, neither expertise, nor even the content). You have to inspire and keep it on emotional level to engage. Don’t copy anybody else style/materials/games. Try to come up with ‘your stuff’, delivered in ‘your way.’ We all value authenticity and passion more, compared to conservative (just logical) sharing of information.

EPAM: Do you plan to create new training sessions soon? What topics are you going to cover?
Simeon: There is demand for ‘Agile Scaling in Software Development’ and ‘Product Owner advanced’ we will cover soon.

Mastering ScrumMastering

‘I am playing a bear attacking ‘poor Tsanko’ (while he is pretending scared), Georgi is a hunter to hunt the bear. The rest of the trainees improvise on different roles: a pickpocketer is trying to rob Tsanko at the same time and another tourist is taking photo of us to complete the picture… It’s all part of the improv ‘Still picture’ game, included in the ‘Thinking outside of the box module’… and we had so much fun, creating scene after scene, after scene…’

It’s been amazing six weeks. Together with Bogoy Bogdanov we delivered ‘Mastering ScrumMastering’ training @EPAM BG

The training (in workshop format only) is complete focused on improving the skills of the participants and consists of 95% practice to 5% theory. No lectures, no ppts, no long and boring talks – just gamified challenges to improve skills in the following areas:

• Communication
• Coaching & Mentoring
• Agile team dynamics
• Delivering talks

Our main goal was to innovate a training encouraging everybody to practice:

• Body language & paraverbal communication
• Soft skills, building emotional connection & rapport
• Coaching and mentoring
• Organizing Scrum events and ensure they run smoothly + facilitation skills
• Removing impediments efficiently
• Influencing decisions
• Presentation skills + teaching techniques (engage the audience)
• Creativity and thinking outside of the box

Each training day, a different topic was covered:

• Starting a new team & persuasion
• Coaching. One-to-One coaching
• Team level coaching & mentoring (Daily standup)
• Team level coaching & mentoring (Scrum events)
• Talks: deliver to engage
• Improvisation in Agile (Thinking outside the box)

And it worked amazingly well. The participants outdone themselves, had a lot of fun, and performed on top of their abilities in each session.

The feedback was also very positive (hopefully we would be able to share the video feedback too):

• 'Fun, engaging, different points of view, a lot of practice'       
• 'Very interactive, full of funny moments, very dynamic & interesting approach'
• 'We covered different topics but not strictly following a traditional way of training. We were put into different situations, where we had the chance to challenge ourselves and improvise'

To enjoy more pictures check the EPAM post.

Begin with the end in mind… shall we?

So, we’ve been reviewing the ‘Agile thinking’ training, together with my friend and lead trainer Jonathan Moss and we jumped into a short philosophical discussion.

At the beginning the training itself teaches that in Agile thinking we should:
1. ‘Begin with the end in mind’ (a well know ‘habit of highly effective people’)
2. ‘Understand the context’

My challenge to Jonathan was, that both of those could be wrongly interpreted by the trainees. The point is - when we adopt Agile mindset and values, we rarely think about the end, I would even argue that there is no end at all. The beauty of our mindset is that we only need a vision and short-term goals in order to deliver value, again, and again, and again. We start seeing our products, services, achievements, even our life goals as a journey, and not as a destination anymore... gotcha, there is no end anymore. Yes, we agree we have a long-term vision. And that’s it – more we see as a waste, as a subject to a change in the future anyway… so why bother?

On the opposite we have the visualization techniques and principles, which are indeed extremely powerful.

First you need to imagine your dream -> (then) visualize it in details -> believe in it -> work your a** off – in order to achieve it

Conor McGregor’s achievements are great example of how far such thinking & believing could lead you in life:

Bending the reality, objecting the facts, trying to tame the Universe so it obeys and supports us in achieving our dreams in details are indeed amazing, extraordinary and powerful tools and mindset…  But those could also lead to a life dedicated to chasing illusions…

And as Agile-thinking-monkeys, most of us are a little bit more practical. We know that ‘Only the ladder is real… the climb is all there is :)’ (by Petyr Baelish's Chaos is a ladder)… And so often we are fine, to bend our dreams, our products, even change our vision in order to deliver value and satisfy our users and clients – here and now. And it is something to be clearly communicated over the ‘Agile thinking’ training. We don’t expect to visualize/understand/know ‘the end’ in our mind in order to start delivering value and get feedback…

Pretty much the same goes to the ‘understanding the context’ principle. We do not expect to understand everything, or even the majority of the surrounding area (the context). We only need to understand the context for the next iteration (step), to work our way through the darkness, just to illuminate more and more of the context with each delivery and feedback.

Agile & Scrum foundations training

Last week we completed another Agile & Scrum foundations training @EPAM Bulgaria. It’s been very intense and at the same time quite pleasant to train the wonderful group of young and hungry (for knowledge) developers at the company. 

Agile and Scrum foundations is training I have been conducting for years. The goal is to fully prepare any team or team members to start doing efficient Scrum and adopt the Agile values and mindset. It covers the following topics:

Agile mindset & values

Introducing Agile thinking and mindset is the most important topic. The idea is not only to help people understand the Agile way of thinking and doing, but also to test if it fits the personality of each participant.

Basics of Scrum, benefits of Scrum and the Scrum team

We talk about Scrum from a high-level point of view, discuss why we use the framework, and what the roles in the Scrum team are. It is followed by a game of Scrum roles. 

User stories & backlog refinement
How to write good user stories and how to initially refine the backlog is covered in the session.

Agile metrics and planning poker

I teach the secrets of relative estimation and we play a game of planning poker.

Scrum events, Scrum artifacts & tools, Kanban

We dig deeper into the Scrum events, artifacts and tools, discuss the basics of Kanban and how it could help the team.

Sprint simulator

A turn-based game, simulating a sprint for the participants to experience it in fast-forward environment.

There are also sessions about XP, retrospective game, and Agile & Scrum test so everybody could check what they learned and how to implement it in their work.

--

Some of the participants feedback:

What was good?

- Short sessions. Well-structured and filtered info – no waste, only value. Recap sessions with questions. Real life examples.

- Games and the practical tasks.

- It was fun, engaging and had real life examples. The games were very practical-oriented.

- Presentations delivery was interesting, not in a boring way.

- The emphasis was on games, practical tasks and teamwork to strengthen the experience.

What could be improved?

- Include more real-life examples.

- Even more games :)

- Make it longer.

Most useful?

- Games :)

- XP and Kanban knowledge.

- Practicing the Scrum events.

--

In conclusion, it was intense… but it was quite a lot of fun too. What is planned next is to deliver the Agile & Scrum foundations training for business and administration to support them in their day-to-day activities. Stay tuned :)

Agile games 2 (scrum introduction, icebreaker, energizers)

I. The airplane game (introducing Agile principles and importance of team work)

It is meant to be fun and entertaining way to introduce teams to Agile. The game  point out how important is the team work, collaboration and spirit in any agile team.

Different types of the game could be played with one or multiple teams (in order to introduce, competition).

1. Preparation
* Print a number of copies of each / some of the airplane/s
(you may use the free plane designs at funpaperairplanes.com)
* Prepare materials - paper, scotch, color markers
* Prepare a chart / list to record each team's results
* Have some extra folks to fill the PO role (outside of the team) for each team and SM role (could be a part of the team) to facilitate

2. Rules
* A team gets one point for each PO's accepted basic plane and two points for each advanced plane. One point is deducted for each failed delivery plane
* Sprint length is 5 minutes. 1 minute for Sprint planning and 4 minutes action
* Demo to the PO/Stakeholders/the other teams is done after the sprint is gone
* Team must choose how many planes could be taken for one sprint, during the planning. The team may take one basic plane, but then it is mandatory to take one advanced before taking one basic again, and so on. (backlog and priorities)

3. Acceptance criteria. You may play with the acceptance criteria and add more (to differentiate) for each sprint.
Example:
S1: plane must fly over 1 meter of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure
S2: plane must fly over 2 meters of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure
S3: plane must fly over 3 meters of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure; plane must have the team logo (simple logo)
S4: plane must fly over 4 meters of chairs; plane must be colored in the team color; each plane properly folded; test infrastructure; plane must have the team logo (simple logo)
etc...

4. Start by explaining the game to the team/s. Explain that the goal is to produce airplanes, the sprint length, the points system, etc...

5. Select a PO (outside of the team) for each team and SM (could be a part of the team) to facilitate. Communicate secretly with the PO/s and give them the acceptance criteria for each sprint. Instruct the PO/s to only share the AC if asked during planning.

6. Show a common backlog consisting of 1 basic, 1 advanced, 1 basic, 1 advanced plane, so on.

7. Start sprint 1 and let the team self-organise and perform in 5 mins.

8. The team/s to do a demo with the planes created; The PO/s have to approve or disapprove the planes after testing.

9. Continue with the next sprints.

10. In the end summarize the score and retrospect over the experience


II. Candy introductions (icebreaker)

It is a fun and relaxing get-to-know-your-team-mates game.

1. Preparation
Get a bag of candies with different colors. Put them in a large bowl.

2. Let everybody get different color candies.

3. Explain the rules to them, and what they have to share before eating each candy:
Red candy - favorite hobbies and activities
Green - favorite places
Blue - favorite memory
Yellow - dream job
Orange - anything the person would like to share


III. Energizers (warm-ups)

3.1. The shoe size
1. Let the team members form a line related to their shoes size as qfast as possible.

2. Let them one by one announce their shoe size to check if the order is correct.

3.2. Untangle
1. Let the team members come close.

2. Ask everybody to hold the left hand of somebody with their right hand. //no grabbing the hands of people next to you

3. Ask everybody to hold the right hand of somebody with their left hand. //no grabbing the hands of people next to you

4. Ask everybody to try to untangle and form a circle.

3.3. Human body star
Ask the people to pair up with a teammate and form a star with their arms/legs bound together.

Agile games: estimation

Recently in Bulgarian Agile Community meetup we discussed some games and techniques used in Agile, related to estimating. In this post you will find three of them, related to estimation:

I. Estimation buckets
It is a way to do estimation of large numbers of items with a group of people quickly (a good alternative of Planning Poker). It also provides a way to establish initial ‘reference value’ to story points when new teams need to.

1. The product backlog items have to be written on cards. It is preferable if the team members are familiar with the items. A table or wall is setup with columns as per the example

If you do not have a reference for story points just leave the numbers blank and add them in the end.

2. Pick a random item, read it and put it in the middle bucket (under ‘8’). It is to be used as a reference.

3. Pick another item, read it, discuss it with the group, estimate it relatively to the first item and put it left (smaller) or right of it (bigger).

4. Choose another item, read, discuss, estimate relatively and place it in the appropriate bucket.

Note: If it is clear that the items scale towards only one of the sides adjust them accordingly. If the first item is smaller – scale all the items towards left (‘1’), or if bigger – scale towards right (‘100’).

5. Continue until most of the buckets have at least one reference item, and the team members get used to the relative estimation feeling and doing.

6. If there are still too many PBIs, divide them across the team members and let everyone silently (without any discussions) place accordingly.

7. Everyone in the group reviews all the items and if there is a need for correction, items are taken out, discussed with the group and placed back accordingly.

8. Write the corresponding number to each card to record the estimates.

The final result would be something like

II. Estimation game (sort of)

This we do together with some of the agile teams in Continental AG. The purpose is to foresee how many and which items will go to the next sprint backlog. It is useful when there not all team members have the expertise to do each PBI. The sprint is set to three weeks’ timeframe.

1. The PBIs are written on cards or tracked in JIRA and the team members are familiar with them.

2. We take the top ten PBIs and put them into four main categories: small; medium; large; huge.
Small – item could be finished up to a week.
Medium – item could be finished up to two weeks.
Large – item could be finished up to three weeks.
Huge – item is estimated to need more than three weeks for completion.

3. Items marked ‘small-large’ fit into one sprint. Items marked ‘huge’ need to be broken down / renegotiated.

4. Then we do some ‘typical resourcing’ as not each team member have the expertise to work on each of the PBIs. For example John and George will work on item one. Steve is the only one able to complete item two. Nick takes item three, etc… The resourcing is done according the prioritization in the product backlog so it is clear which stories could go into the next sprint.

5. Sometimes it’s not possible to take all highest priority items and the product owner is triggered to choose between 'competing items'.

6. In the end the team comes with a proposal how many PBIs and which ones could fit into the next sprint, as per the example (the green dots):

7. The product owner agrees or renegotiates the items, together with the team.


III. Project box experiment
The purpose of the ‘project box’ is to define requirements for an MVP. It could be used when a large number of stakeholders (e.g. in different departments) need to provide requirements and priorities for a product.

1. Provide each department/stakeholder group with equal amount of ‘fake currency’ or vote points.

2. Let each group define and visualize their idea in a form of a product with characteristics.

3. Individuals from each group to present to all the other groups the vision of the product (MVP) in just 3 minutes.

4. The other groups have to spend their ‘money’ or vote points on each presented MVP.

5. The most ‘expensive / voted’ MVP wins and is a candidate for production or further discussion / refinement.

---

Hope those are useful to you, guys; as usual please leave your feedback in the comments.

Startups, Entrepreneurship … and Agile

Last Wednesday I had the pleasure to be part of the Startup Founder 101 event ‘Meet Experienced Startup Founders’, and the two major speakers Viktor Bilyanski (Founder and CTO of Scalefocus) and Hristo Neychev (Founder & CEO, Tryad Games), shared their experience in entrepreneurship and startups.

Going over my notes here is some assorted key wisdom:

The reality is brutal - 95% of all new business initiatives fail to survive and die in less than 2 years

The most important for each startup:

• Discover, believe in and communicate your VISION
• Find an amazing CO-FOUNDER (really difficult)
• MOTIVATION – keep going when you are rejected, and rejected you will be… a lot
• Find your first CLIENT/INVESTOR

Starting up a new business is like staring a new project – it has a beginning and an end. And the time slot is really tight. You can always go back to the corporate business if it doesn't work out.

When you fail, you still acquire experience and memories. The successful entrepreneur started approx 10 startups throughout entire life.

What’s really great about startups is that you move with your own speed, you only have to convince your co-founder and then it’s a matter of minutes to work on new idea.

To find a great co-founder look for somebody close, somebody you know for years. Somebody serious, motivated and admirable. Most of the startups die due to co-founders divorce and/or team disrupts. And high pressure is going to increase the chances any of those happening… and high pressure there will be.

Fundraising is difficult and at the same time it is important for every startup to get money as quickly as possible. Somebody investing in your business is good not only because it validates your idea/vision, but also because the clock starts ticking and your startup must start delivering. You all become more disciplined… and discipline you will need.

Your prototype, your product, your numbers worth more than the raw idea in your pitch. The investors will invest in your team and the execution not your idea. They want to see a successful team – members to have successful tracking records.

You pitch on vision or numbers and it is much better to pitch on numbers. The successful pitch would outline two major points:

• The TEAM - who are you; how successful are the team members so far; what is the endurance and the sustainability of the team
• TRACTION – how many users/clients do you have; what is the trend; clients profile and sustainability

Angel investors will invest in 1 out of 40 startups presented to them. Venture capitalists will invest in 1 out of 400. If you have rich friends/mentors try them first.

Coming up with an idea you might follow a process like:

• Set FRAME/ VISION/ the window of opportunity / the market
• And then use standard creative process, e.g. 'brainstorming'
• VALIDATE your ideas fast – use paper; Excel and simple tools to prototype fast

Persistently look for feedback – involve users/clients and improve, discard and innovate.

Most of the startups aim for online business because it is easier to scale online.

The biggest challenge is to define and develop your MVP. It needs to be good enough for your market but at the same time it needs to be built quickly to be validated. Be careful in B2B – you cannot afford to show not-polished product.

Do not hesitate to interview people about your product and expected price, but the only validation for the price happen when real purchases are made.

If your startup product is some sort of a service, keep in mind service offering companies do not scale well and depend on their founder too much. Try growing from service to product business.

--

So far so good… but where is the Agile part?
Everywhere… I have always admired startups as they are the truest possible embodiment and validation of the Agile philosophy. Deliver sooner than later, empower teams, embrace the change and be lightning-fast in adapting, continuously improve and deliver, eliminate waste, collaborate well, promote innovation and bow to enthusiasm – all the major principles are followed relentlessly – and it is pure joy to watch and/or be part of.

Scrum good practices and hints #01

Recently I’ve participated in the Continental’s CDS department strategic workshop for 2016. The topic of Agile & Scrum development has been heavily discussed, and I am providing some of the points as a reminder of the good Scrum practices.

Formulate sprint goal
It is difficult to do so, when the sprint backlog is full of non-related stories. Nevertheless combining stories into epics and themes and committing to them into one sprint brings value. Not only the stakeholders have clear message what could be expected after the iteration, the team also feel focused and united under the same goal.

Prepare the review on the planning
During the sprint planning - acceptance criteria need to be present for all the user stories and it should be clearly communicated what would be demoed over the sprint review in the end. The topic is again - visibility and transparency – what could the stakeholders and the product owner expect in the end?

Grooming preparations
It is inevitable that some teammates are busy and do not have time to look at the product backlog before the grooming session. The situation has to be avoided. Everybody should come prepared and at least should have rough idea of the stories that are to be groomed.

Limit the task granularity to a maximum of 1-2 days
It is a good practice and the reminder came from the Romanian colleagues. Just putting a generic ‘development’ task and estimating it to 60 hours (10 days) doesn’t help with the transparency, right?

Write comments to the user story in JIRA regularly 
Usually the comments in the tracking system come in the end when the story is completed. This practice does not really help the product owner during the sprint when information about the progress is needed.

Exchange teammates to share good practices
This one has been discussed for quite some time. It happens that team members of one team work together with team members of other team for some days but it’s not really a regular practice. And as there are different products, it is challenging to change teams understanding new expertise has to be acquired.

Do not skip the ceremonies
The Scrum ceremonies should not be skipped. And it is not because a guru, trainer or the scrummaster say so, but because they are valuable. Skipping ceremonies indicate teams do not see the value of them and is there should be a reminded session why/how the ceremonies help all of us.

Keep the physical board updated
I am a big fan of the physical Scrum board. Although JIRA/Trello/Asana/Rally/Orange are commonly used somehow the magic disappears online and the vibe is much different when there is a physical Scrum board. Both physical and online boards should be updated daily, either in the end of each day or during the daily standup in the morning.

Bodybuilding VS Scrum

For those of you who don’t know me I am passionate about sports – especially strength increasing sports. (and for those of you who know me – I’m still passionate about sports :) I exercise at least 5 days a week. Usually I work-out in the morning, just to be in a hurry later for our daily stand-up, and the last time on my way to work I’ve been thinking about all the similarities and differences between bodybuilding and Scrum… sounds interesting, right?

Not everything is alike, and Bodybuilding is mainly solo activity while Scrum is all about team effort. Nevertheless the fundamentals are comparable:

* Iterate to continuously improve your product / body & strength

* Focus, self-organisation, discipline, determination, flexibility, learn from mistakes - are all major traits

p.s. looks like I’m much better in both bodybuilding & Scrum compared to hand-drawing :)

ALE 2015 recap

“I cannot teach anybody anything. I can only make them think” 
- Socrates

Gathering knowledge is important… And sharing knowledge is even more important. Deciding to present the most interesting topics (to me) from the amazing ALE15 experience my idea was to challenge the folks with the status quo in our beloved Continental and Predistic. It was not about providing answers and solutions (I’m sorry – just don’t have them all) – but to inspire and challenge.
(if you would like to just browse the presentation – scroll to the bottom of the post)

---

Started with the ‘Real Options’ concept presented by Chris Matts (@PapaChrisMatts)
The idea of pricing the options is something we always struggled with. In a technical industry rarely people ask ‘why’, and usually just ‘what’ and ‘how’. But only after deeper understanding what the value of the option is we should turn it into a commitment…

So memorise those:
- Options have value – and we MUST calculate it and make it transparent
- Options expire – and we MUST know when and why they expire
- Never commit early unless you know why

---

‘Your culture in the mirror’ presented by Ivana Gancheva (@IvanaGancheva).
This was the soul touching presentation (for me), probably because it tells the story of General Motors’ ‘faulty ignition switch’ and the death of more than 100 people unofficially related to the technical problem. I work with the Automotive industry and I am not with them to kill people… and none of my colleagues – all brilliant and amazing would be ok if the safety of the passengers are endangered by our products. But ‘culture eats strategy for breakfast’ and it’s a strong and difficult beast to handle.

Changing company culture is something I have always been engaged with but at the same time somehow refused to believe how fundamental it is. ‘No matter what the culture is if you inspire and lead by example – it will all be alright in the end’ I always though. But the beast is strong and underestimating it means that a leader needs to break the walls with the head. And it hurts a lot and the chance of failure is high. So we really need to start from the management and then engage everybody and persistently integrate change after change after change… I’m up to the challenge … are you?

---

Design thinking, presented by Mariana Ivanova (@olive_pro)
Had doubts whether should those slides be included in my recap. As the industry is highly regulated and we are limited on every level it is a shame the great minds working here are trapped in mundane tasks like fitting, fixing and optimising every day. Innovations and thinking-outside-of-the-box scarcity is frightening. The focus is usually on cutting costs, squeezing the maximum performance of the hardware and delivering on the lowest possible price instead of innovating the features of the future cars… yes, it is sad.

---

Bernhard Bockelbrink presented Sociocracy 3.0
A neat idea, framework or just a way to involve everybody into the decision making processes in the company. Circles are perfect - so let's use them - put everyone in your team into a circle and debate, argue and agree on every decision or policy. Then elect a team representative to sit into the representatives circle and agree on higher level. And so on and so forth. We would like to gather more knowledge, inspire creativity and increase the engagement and commitment for everybody.

---

'As a leader you are responsible for the emotional state of your people'... Boris Gloger (@borisgloger) said, and I would add that everybody should be responsible. Endorphin, Dopamine, Serotonin, Oxytocin - all known as the happy hormones. Is there an easy way to help release them in the bodies of our fellow professional soulmates? Simply saying 'thank you' and recognising the work of our teammates proves to do the job perfectly. A little hint - 'don't wait for the retrospective - make it a daily habit'.

---

For those of you who recognise my ugly handwriting - yes, it was I, engaging some brilliant minds (in one of the open sessions) into discussing 'How to engage the team into uninteresting tasks'. Really grateful for all the beautiful ideas the folks generated. The one, my evil half is particularly interested in is 'Let the team fail...' as I usually don't do this :)

---

Olaf Lewitz (@OlafLewitz) and the different stages of 'motivation'. I would proudly say - usually we are at 'We do it, because we have to' and it's not that bad. Getting to 'We do it, because we want to' and staying there would be quite challenging for any team I would say... still wanna see the sustainability (for a long period) achieved somewhere.

---

Meet Bob (not on the picture :)). He is the person (in any team) who is the one and only capable of doing specific tasks and is usually assigned first. Staff liquidity principles though, release Bob from actually doing the work - he should only train until we have 3 masters in all domains. Then Bob could go and train folks from other teams, spreading the knowledge.

---

My two cents to the conference - Uncommon SCRUM practices - follow the link or look at my previous post if you dare to challenge yourself with some forbidden practices :).

---

The blockers should be measured! (@mattphilip)
They run a project in Asynchrony only to reveal huge amount of time wasted in dependent stories. The most interesting revelation though was discovering the average delivery time in their flow is about 5-6 days instead of every 1-2 day/s (something the teams strongly believed in). The message is: 'always backup your beliefs with data and don't just rely on your gut feeling'. Matt's slides are all shared on slideshare.

---

... and some basics on 'how to influence better teams'

---

(@rachelcdavies) on some cool ideas about 'building learning into teams'.

Coding dojos, pair development - and more than two devs, lightning talks, swapping teams, and even knowledge tokens. All great practices to share the knowledge in and out of your organisaton/team.

---

And finally - this is how they visualise the daily time spent into a team in Unruly. Looks cool.

---
The entire presentation on slideshare (the questions are to challenge the colleagues to provide back some thoughts and feedback):