Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Scrum Transformation - 1 year after - our story - Agile by Example 2017
Similar to Scrum Transformation - 1 year after - our story - Agile by Example 2017 (20)
Recently uploaded
Recently uploaded (20)
Scrum Transformation - 1 year after - our story - Agile by Example 2017
- 1. 1 year of transformation - our story Agile by Example 2017 | 10.10.2017 Piotr Nabielec Marta Borkowska- Bierć Paweł Gawliczek
- 2. 1 year of transformation - our story Agile by Example 2017 | 10.10.2017 Piotr Nabielec Marta Borkowska- Bierć Paweł Gawliczek
- 3. Software is a process problem. It is a matter of designing the right system. Software is a people problem, not technology problem. OR
- 4. Transformation is dealing with software and products, but is all about people. Scrum is only a part of the picture (marketing, sales, ?) (bugs, technical debt, ?)
- 6. IT organization Flyhacks Vola.ro Fru.pl … FRUSTRATIONS
- 7. Who is responsible for what? Do we have a team?
- 13. Pawełi Marta
- 14. Choosing the right Product Owners
- 16. How to help people take ownership?
- 18. Whooops… The patient is still alive
- 20. Is he still alive? What do we need to monitor?
- 22. Leadership is all about behavior.
- 23. Could you possibly please be so kind and do that? I would like you to do this and that and the deadline for that is… Firmness
- 24. Immediate feedback for behaviors – positive and negative
- 25. Quarterly feedback – you are a part of the system
- 26. Talk a lot about people
- 27. What we still fail at – precise actions for people. We do sth and patient does not react.
- 28. You need to have resiliance and courage
- 29. Take an opportunity to change even more
- 30. Let people feel fear and stress
- 31. Get yourself a team – do not do it alone. Take care for leadership skills. Ifyou want totransform…
- 32. Use a lot of feedback. You can not overdose it. Be prepared for difficult decisions. Ifyou want totransform…
- 33. HAVE YOU ever worked for a startup that was successful?
- 34. 2 month project ends as a 2 year journey.
- 35. WE need scrum!
- 37. STRATEGY 1: E-commercemanager as a Product Owner Great because he understandsmoney, right?
- 38. Strategy 2: FlyHacks business kanban
- 39. Strategy 3: IBE & CORE Business kanban
- 40. CHANGE IN THE TEAM & Product SETUP from well defined silo’ed teams TOGROUP COMMONNEEDS& COMMON BACKLOG
- 41. Skeletons in the closet!
- 42. Problem no 1:Technical debt
- 43. BUT WHY TO DEAL WITH IT? Deliverprojects on timewithless capacity cost.
- 44. HOW TOMANAGE IT WITH SCRUM? FIRSTRULEOF DEALING WITHTECHNICALDEBT STOP DOING IT! SECONDRULEOF DEALING WITHTECHNICALDEBT CREATEA PLAN,ASSESSBUSINESSVALUE, TALKWITH YOURPO! AND FINALLY AGREEONAPROCESS
- 45. Our process? 20% of iteration capacitywe spend on dealing with technical debt What is still not working? • Plan not shared well with PO’s (westill have separate product plan and tech debt plan) • Teamsare not engaged enough
- 46. ThingI am most proudof isa changeof a mindset HALF A YEAR AGO CTO: ‘WHY YOUARE NOT DOING UNIT TESTS?’ TEAM: – WEDON’T HAVE TIME – BUSINESSIS PUSHING – WE CAN’T BECAUSEIT’S A MONOLITH APPLICATION – … ‘ TODAY • LASTWEEK TEAMORGANIZEDTHEMSELVESTO TALKABOUTMOCKS TOWRITEBETTERE2E TESTS(WITHOUTMEASKING) • EVERYNEWPROJECT HAS>75%OF TEST COVERAGE PEOPLESTARTTO GET PROUDOF THE WORK THEY DO
- 47. THANK YOU
- 48. 1 year of transformation - our story Agile by Example 2017 | 10.10.2017 Piotr Nabielec Marta Borkowska- Bierć Paweł Gawliczek
Editor's Notes
- The story of our journey, no fluff. Three of us
- As you all know
- The story we would like to tell is about two main, very simple ideas
- To show you how important people are in the transformation, let’s see how I was hired
- The picture I saw was this: Speed, quality Changing priorities
- Slack channels were red, mixed messages who is responsible for what, separate developers and business people
- Some problems that I’ve seen I believed could be fixed by adopting Scrum
- I had an opportunity to train most developers, testers, some business people, managers, the board. I could see a long list of improvements, but happily could see passionate, dedicated people.
- There were few people problems: Strong personalities and responsibility taking Some communication channels broken Autonomous, self-organizing teams
- Few business problems: Not clear how to set priorities, Not clear how to calculate how much we were doing. How to run an experiment and evaluate based on analytics? Business was lacking a clear structure
- Few technical problems: Complex code branching No coordinated automation efforts Growing technical debt starting from architecture and spaggetti. Knowledge only in people heads.
- Paweł and Marta supported by company board made a huge impact Passionately working. Inviting people to join
- Scrum Teams part was easy. We were struggling to choose the right Product Owners. People and business problem at the same time
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- I had growing problem with helping people take ownership. I helped to coordinate a year and quarterly planning and failed miserably. Scrum part was easy, changing people’s mindset, help take responsibility – that was a challenge
- This was a day that I called Marta nearly crying, because the meeting of managers with the board went to bad. I didn’t know to progress with this. And this is where Marta and Pawel took the lead.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Clearly prioritized backlog, single individual in charge, Cooperating with others, estimating business potential. That was too much.
- Have you ever worked for a start-up that has been successful? When from a team of couple of people suddenly you enter the office and all around you you see new faces?Things were no brainer before now start to be an issue. Out of a sudden you have couple of teams and communication skills start to matter, there are no standardized roles, there are no processes. There is no responsibility?
- Application that was small and compact suddenly has 1 min lines of code and project that was supposed to last 2 months end up a 3 year endeavor?
- After 2 weeks in I was already sure that I need SCRUM. I call Piotr, setup training through whole organization. Starting with all execs and all employees. SCRUM guide basically says: setup team, have PO, have SM, create backlog. Trival task but out of a sudden when you want to do it right its not that trivial. I knew I didn’t want SCRUM for the sake of having SCRUM. I wanted to implement core values of transparency, collaboration and agility in our organization.
- So how to get to a good backlog? In mid size company PO is a person that has huge reposnibility.
- take e-commerce manager and make him PO. He will be excellent because he understands money! How right we were. He was talking only about money (and team had hard time talking with him).
- second team went in from different angle: they set together (analysts, UX, managers, BAs) and created a Kanban process where they have all fancy ways of ranking the business value, with the goal of creating perfect story … that were very detailed and long … BUT developers were begging for an hour through a day where no-one from team/business will ask them questions about future story details. Soon all Kanban cards were in state ‚ready for development’ …
- another team went with simple kanban … but didn’t share with the rest of stakeholders how the kanban is working and the PO were not great with communicating out what is happening
- What we did? All that Marta mentioned. Management team, strategy on group level and product definition that has sense both from business side and IT side. We decided to create a head of product role (chief PO) that will synchronize work for all teams and we put process in place that will emphasize business value on every step of the process. To make sure everyone gets it.
- What happens when you implement a process that is already quite repeatable and people start to play along? You find skeletons in the closets! And thats a good thing.
- 3 months after SCRUM implementation stated we realized that the level of technical debt is way worse than we thought. Its not that we didn’t know we had it. Its more like one day no-one CTO + architects + developers talk application is badly written next day nearly EVERYBODY knows. Including the board. Boy that was fun ;)
- Hate refactor for sake of refactor Do actions that are going to bring value to the business.
- FIRST RULE OF DEALING WITH TECHNICAL DEBT STOP DOING IT! SECOND RULE OF DEALING WITH TECHNICAL DEBT: CREATE A PLAN, ASSESS BUSINESS VALUE, TALK WITH YOUR PO! AND FINALLY AGREE ON A PROCESS
- 20% of iteration capacity we spend on dealing with technical debt What is still not working? •Plan not shared well with PO’s (we still have separate product plan and tech debt plan) •Teams are not engaged enough
- We are far from done. But we managed to get to a situation where entire organization reacts to business changes … according to priorities. Project start to be delivered, some even on time, and the code has better quality. The more I talk to people the more i hear they are proud of the work they do … and thats something super important for me.
- Our agile journey is not done yet. Actually a lot is ahead of us. 15 min is a lot to share so much experience with you. Please feel free to approach us and talk.