Download to read offline
More Related Content
Similar to Group process by example
![Lect 1 Number systems and base conversions. [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/lect1numbersystemsandbaseconversions-260111134109-67c2d865-thumbnail.jpg?width=640&height=640&fit=bounds)
Group process by example
- 1. Group Process byExample Agile Tour London A PO’s and SM’s perspective
- 2. Łukasz Aziukiewicz Scrum Master @aziuk_l MartaKossowska Product Owner @marta_kossowska
- 3. ● Individuals andtheir interactions ● Delivering working software ● Customer collaboration ● Responding to change ● with some issues...
- 5. ➔ no commonproject goals ➔ scattered team members micromanaged by leaders
- 6. ➔ “never ending”stories ➔ bug fixing and fighting fires
- 7. ➔ no contactwith client ➔ lack of trust between the team and stakeholders
- 8. ➔ priorities changedevery day ➔ no planning perspective
- 9. ● 4 phasesevery group goes through ● no strict time frames ● can be accelerated or hindered
- 10. “Bugs yesterday, bugstoday (bugs tomorrow and forever and ever)”
- 11. ● Product Backlog- what is it? ● unclear business context
- 12. ➔ building asafe environment ➔ giving them norms
- 13. ➔ giving examples ➔involve team to create user stories
- 14. “Scrum doesn’t worklet’s do Kanban”
- 15. ● different trialsto organize product backlog ● poor quality & most of time dedicated to bug fixing
- 16. ● wait itout - don’t go to war ● let them try and fail ● leave space to inspect and adapt ● appreciate productive behaviours
- 17. ● “let theteam destroy everything” ● try different solutions and inspect if they work
- 18. “This other teamuses a cool calendar that helps them do sprint planning - why don’t we try it?”
- 19. ● agile producttechniques actively used ● improved communication with stakeholders
- 20. ● give theteam space ● show that the changes have an effect
- 21. ● involve teammembers in starting new initiatives ● facilitate contacts with business client ● focus on quality
- 22. “What can wedo to be even better?”
- 23. ● responsibility forwhole product and its quality ● more partnership with business stakeholders
- 24. ● up theante - constantly try to improve ● don’t get in their way
- 25. ● start withWHY and let the team decide HOW ● openness for initiatives
- 26. ● Individuals andtheir interactions ● Delivering working software ● Customer collaboration ● Responding to change
- 27. 1. Build asafe environment so people can start storming. 2. Don’t fight the team in storming stage. 3. Give the team space for norming 4. Reap the benefits of performing
- 28. Q&A Marta Kossowska Product Owner @marta_kossowska ŁukaszAziukiewicz Scrum Master @aziuk_l
Editor's Notes
- #2 We’ll tell you a story of a team we’ve worked with for the past few months. Fast paced, so bear with us But first of all - who are we?
- #3 certified Product Owner with eight years experience in software product development, mainly in e-commerce and financial area played different roles: project manager, business analyst, product manager and product owner cooperating with teams from different type of organizations For nearly a year I’ve been working for STX Next which is an agile-oriented software house. With my team we develop complex banking system for one of european banks. What I found most excited about agile is its focus on relations between individuals when at the same time it doesn’t neglects the product and the value it provides for client. --- Scrum Master and Agile Coach - 10 years in software development, 3 years in agile environments. mostly with financial institutions (banks, polish paypal) now in STX - agile software house specializing in Python. Interested in psychological aspects of working with a dev team - hence the subject So where does our story begin?
- #4 Łukasz wchodziliśmy do istniejącego od dłuższego czasu zespołu
- #5 we expected decently functioning dev team but what we found was quite different than our expectations
- #6 Instead of interactions between indyviduals we found group of scattered people where everyone worked on something different there was hardly any communication between team members, no common goals and plans one strong team leader who decided what every team member should do
- #7 Instead of delivering working software, we realised that stories and tasks not completed for many sprints even if something was developed, not be tested, when was tested, new bugs were reported so it was hard to say if something was done or not main focus on bug fixing list of more than 100 bugs and whole month only bugs with no new features
- #8 Team didn’t colaborate with the customer, due to almost complete lack of contact with him. The requirements were delivered to our team via another company No discussion with client was possible, so the team did literally what client requested (e.g. multiselect implemented as radiobuttons).
- #9 priorities changed all the time, there was chaos in place of agility nearly every day team leader got a call from client who informed about another “silver bullet” that needed to be delivered right at the moment no further plans were known With this initial circumstances we started to work with the team. After couple months we noticed a huge change. We will tell in our presentation how it was possible. When we looked back at the way we did with our team, we discovered that the process we went through recalls very much the model described by american psychologist Bruce Tuckman.
- #10 Łukasz Tuckman - amerykański psycholog, który badał dynamikę grup Forming - orientation, dependency Storming - team sees their differences, conficts start Norming - team figures out norms to work by Performing - truly effective work zapytać na koniec jak im się wydaje gdzie był nasz zespół
- #11 Forming - also called orientation, dependent on leader, gets to know each other, no open conflicts, no “team spritit” examples: daily scrum - I worked on bugs, I’ll work on bugs today, no common goals unimportant issues on retrospectives - new paper towels in bathrooms, real problems not mentioned team leader micromanages the team (e.g. assigns work), noone opposes him they don’t really seem to care
- #12 The process of product development was really chaotic in this phase: no product backlog, so nobody new what team is working on, what is planned next, what are the priorities team has no idea about the business reasons behind the changes client requested
- #13 examples: making sure everyone speaks at retrospectives and his voice is heard, not interrupted if a team is totally new - team building excercises, get people to know each other better personally keeping the rules of scrum not requiring proactivity - being a bit directive
- #14 Team in the forming stage is not strong enough to undertake any initiatives. So instead of expecting their proactivity it worked better to give them ready-to-use examples: I started with creating product backlog to introduce a bit of order to our chaotic environment. This first product backlog serves as an example for the team how the requirements can be managed Next thing was DoD example,I said that we had problem with never ending stories. One of the reason was that nobody really knew what the done meant. So we used DoDs, from others teams, to show what aspects should be covered to consider story as done Another example is the user story - by giving a team a well defined stories with acceptance criteria, we proved that the requirements doesn’t always have to be so ambiguous and unclear neither described as a 100 pages document with tens of unreadable tables. by involving team into creating US we started to answer question “why something needs to be done?” - even if we often had to guess, team was forced to think about business reasons and value behind the feature Challenging status quo was not accepted by everyone on the other hand team members started to feel more confident which caused the team to move into the storming phase.
- #15 Storming team feels confident enough to see differences between each other Zespół długo był w formingu, przez co storming był bardzo intensywny examples: no daily scrum no planning designing a kanban process and avoiding any scrum naming (sprint = iteration) personal attack on SM
- #16 The struggle for supremacy so characteristic for storming, was very well visible within two areas related to product: product backlog: almost every team member had his own idea how to organize and manage it one created own ‘to-do’ list in bugzilla, another tried to use intranet to create some kind of kanban board, PO kept forcing usage of JIRA) and nobody wanted to agree with others ideas test automatisation: no automatic tests were written, some team members insisted that it made no sense because system was too complicated, others wanted to introduce test automatization but couldn’t agree how to do it. As an effect we still neither backlog nor automated tests.
- #17 examples: waiting it out letting them try and fail - if they wanted Kanban - explaining what it is and letting them experiment keeping retrospectives alive reminding of goals for implementing agile, not the scrum framework - asking how they’ll know their progress, don’t tell them to do a daily scrum showing that conflict is something natural and can be productive
- #18 Surprisingly it was a good thing to let team destroy the “old order”. It created a space for building new norms and frames accepted by the whole team. Proposing new solutions helped to facilitate this process. For example, when team decided they need no daily, we accepted it and started to propose different ways to ensure team’s work synchronization. At one point we installed white board on the hall next to the kitchen and posted postits with some stories team worked on. Spontaneously more people started to gather near the board to inform each other what going on. Anather example relates to the cooperation with external team, we partially depended on.It was very tough, becouse they didn’t deliver so we weren't able to deliver either. At every review we complained about this team, one time we decided stop complaining about what they didn’t deliver and start to praise them for what they delivered even if it was only a little bit. It really helps us to improve cooperation with this team. After a series of experiments, emotions gradually calmed down and team started to work work in more cooperative manner which marked a beginning of norming.
- #19 Norming - team identity forms and rules are crafted u nas zaczęło się od podziału na 3 podzespoły i friendly competitiveness examples: splitting into 3 smaller teams with their own sense of identity (spanish inq) working out DoD’s scrum boards tailored to each team’s needs sprint goals start making sense and motivate people now we’re getting somewhere
- #20 Team appreciated scrum not only as a process but also started to value agile related techniques for product and requirements management finally we created complete (and one) product backlog thanks to that it was possible to make short time plans user stories, acceptance criteria, test scenario became a standard our communication with stakeholders improved very much and we saw that they started to trust us and appreciate what we’re doing
- #21 examples: backing up a little, let them solve their problems - taking less responsibility for retrospective action items letting the team be proactive - don’t be a “scrum mom”, they’re grownups counting the number of silver bullets (unplanned tasks in sprints)
- #22 During the norming stage our team was very enthusiastic and willing to experiment with new techniques for agile product development: we started to use story mapping and personas to have better understanding and more accurate delivery plan for our projects we started to communicate directly with our business client - both developers and business were involved into new projects from the very beggining we started to use different techniques for backlog estimation so it was possible to make commitments to our stakeholders After this fascinating period of experimenting and discovering the way we used to work stabilized - that was the sign that the team achieved next level in its development.
- #23 Performing ground rules are set; we ąre improving them iteratively, no everyday revolutions, there’s no I in TEAM examples strong motivation towards achieving sprint/project goals - asking during standups working towards enforcing set rules rather than creating new ones (we need to be writing automated tests, stick to DOD) I thought - I finally have a scrum team
- #24 Product development process is better organized and effective because the team already worked out the patterns and good practices The quality is better as the team members takes responsibility not only for single features but for whole product Team’s assertiveness empowers them to say clearly when something doesn’t meet quality standards and is not ready to be delivered for client Tests aren’t neglected any more as it used to be before Team is proactive and can propose best solution by themselves, negotiate with stakeholders and receive regular feedback from business Others are following our example (teams we cooperated with)
- #25 examples: being demanding, throwing them off balance - asking the team “can we do better?” or “are we living up to our set standards?” being away from time to time - showing them that they can handle themselves don’t forget it isn’t the same as RI - you’ll find spaces for improvement
- #26 Performing team is very autonomic and independent so it is useless to give them strict instructions and tightly control their work. So what do I as a PO do at this stage: focus on business goals instead of deciding how something should be done bring the team closer to the business stakeholders plan work for next sprints so the team knows what will be expected in the near future - nothing is so demotivating as the feeling that we’ve got nothing to do be available for the team (also physically), answer their question, support solution seeking but let them decide
- #27 At the end of this process (if this process ends at all) we can say that we have: a team that can effectively work together implementing common goals people in different roles (front-end developers, back-end developers, QAs) that can collaborate with each other sharing their knowedge and experience we’re able to deliver working and complete features in every sprint we can guarantee the quality of delivered software, thanks to strict testing procedure before every distribution to client (the number of bugs on the list - 3 instead of 100) we get into direct communication with our business client so we,ve got first-hand requirements and quick feecbacl we know end users of our product which helps us understand their needs better our environment is still pretty unstable and priorities changed often but we’re conscious of the impact it has on our performance, and we are more assertive so we ‘re not afraid any more of asking “WHY”