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)

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.