Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile PM
Similar to Agile PM (20)
Recently uploaded
Recently uploaded (20)
Agile PM
- 1. Agile Best Practices Techniques forsprint planning, reviews, retros, etc.
- 2. Kendal Kirsch 1 son – Knox (4) 1 puppy – Bodhi (4mos) #boymom Associate’s Degree in Business Bachelor’s Degree in Project Management Things I enjoy: Camping Sand volleyball Being on the water Being with family and friends Concerts (please come back)
- 3. Why Agile Project Management? Agile
- 4. 4Core Values of Agile Project Management Individuals andinteractionsover processes andtools; Working software over comprehensive documentation; Customer collaborationover contract negotiations;and, Responding tochange over followinga plan. Agile
- 5. 5Agile & Organizational Culture Agile is people-centric 3 Pillars of Agile Transparency Inspection Adaptation Engaged team members help in creating & sustaining self-organizing teams Strong engagement bring autonomy & ownership which can be built by trust
- 6. Agile Best Practices Best Practices
- 7. 7Agile Best Practices Peopleare mostimportant Routineiskey EnsurethatthePO isactivelyinvolved Setrequirementstoensuretheteam haswhattheyneed Key playersare involvedinthedaytoday Best Practices
- 8. 8 People. Knowing your teamis important 1:1s Key touchpoints Ensuringtheyareengaged andfulfilled Settingexpectations regardingAgile ceremonies Best Practices
- 9. 9Agile Ceremonies SprintPlanning SprintRetro BacklogGrooming SprintDemo DailyStandup Best Practices
- 14. 14 Uncle Bob was WRONG! Metrics Velocity Burndown Teamhealth Accountability Noassumptions Best Practices
Editor's Notes
- While obtaining my bachelor’s in PM, I had to learn everything the PMBOK offers - from traditional pm to agile. Waterfall is not something I am about and that is why I leaned on software development and agile. I didn’t like doing all the work upfront for my class like I would with construction. It felt very rigid and not flexible. Agile really made it feel like you could get work done in smaller increments and still deliver to your customer. I was definitely drawn to Agile bc of the flexibility and accountability.
- I am very pro to make Agile what works for your team. There are guard rails and parts of the process that you should be doing, but you can customize the process for what works for your team. I was on Great Plains Beef with 3 other people - a small size team, if you will. We customized the Agile process to work for us. We pushed retros to once a month – this was because we were such a small team that was in constant communication. We had sprints, but we really did a Kanban style workflow. This made our interactions with our customer very frequent and it helped ensure any feedback was immediately added into our backlog and prioritized. This worked for us while still tracking metrics and monitoring customer inputs/feedback.
- Agile is people over process – I truly care about the people I work with. Agile doesn’t mean it’s the wild wild west and there is not process in place, even though some truly believe that. Agile process hold people accountable. We can know what’s happening and effectively change things that we are working on quickly to address any issues or changes in priority. I feel like Aviture’s culture really jives with Agile. We encourage our team members to think outside the box, we let them be their own CEO or CTO. We encourage learning and let our employees try new things. I came from BCBSNE and they said they were Agile, but to be honest, it wasn’t like we have here today. It was process heavy and do things bc the process or book says to. Which is why when I had the chance to come on to Aviture, I jumped.
- Know your people. Personally and professionally. You don’t have to be best friends, but understanding their likes/dislikes, all that is necessary. I try to regularly do 1:1s with my team members – at least twice a year, but sometimes more. A smaller team is obviously easier to make that happen, but my Carson team is large and it would be a lot of have 1:1s more than once a quarter with everyone. But this is face time with my team and understand them. Routine – recurring meetings for each Agile ceremony, keeping things standardized. Starting with Team norm meetings and Definition of done exercises. Ensuring everyone is on the same page for how the team works and its processes. Proper documentation of these things. Proper documentation of meetings/minutes/action items. Known contacts for business and technology – decision makers. Knowing who the PO is, who the end users are and knowing their wants, needs and expectations.
- What do they work on? Are they REALLY good at frontend work – UI, react, etc. Are they more experienced in DevOps and backend solutions? What technologies are they proficient in? React, Azure DevOps, Amazon Web Services? I may not know what these really are or what type of code, but I can support my team member knowing what they are good at and getting them opportunities to flex those muscles. What type or work interests or excites them? I have met with many Aviturians across my projects the past year and a half. We have a lot of people interested in machine learning and AI items. Or we have people who are really good on the backend and they want the experience on the frontend. Understand their work and personal life dynamic – Do they have something significant going on in their lives that affects their day to day. Do they have small children who have been home for months over a pandemic? Just knowing what is going on and how they work with that, is key. I want to be able to help them balance their day to day.
- Fist of 5 – not sure if everyone knows this. All team members must be a 3 out of 5 (fist of 5) Anyone lower than a 3 we must keep talking through the sprint work. 5 – love it – could champion it 4 – Support it – good idea 3 – I can live with it 2 – I have reservations and need more discussion 1 – Will not move forward – opposed to this Sprint Planning – All team members must be a 3 out of 5 (fist of 5) Anyone lower than a 3 we must keep talking through the sprint work. Stories must have a description that is easily understood by a non-technical person. This help ensure we know the business value of the story and that the PO and business can understand what we are doing. Stories must have AC. Jira doesn’t have its own place for AC, so I just make a bulleted list. I talk through with the team and the PO as to what this AC is. It needs to be clear and concise. Lastly, all stories must be pointed. The team must agree upon the points. Once the sprint is started, the story points should not be changed. The team should use this as a learning experience when it comes to pointing. Review why it was not pointed high enough or was pointed too low. Sprint Retro – I like to change the retro we do every sprint – this keeps things fresh and people engaged. The retro should have actionable items that are documented. People. They are again the most important. Ensure your team feels like they can be open and honest – safe space. Identify areas of improvement for the next sprint. Review action items at next retro. I am a firm believer of having a retro after every sprint. I also understand that that doesn’t work for some people or isn’t ideal. If you have a smaller team or an extremely large team, I would suggest at the very least having a retro every month. Retros help the team work through items and encourages them to be candid with their feedback. If you have a really good team and they are providing candid feedback regularly, retros could be spaced out. But if your team isn’t the best that those tough conversations, I would suggest having more regular retros and encouraging your team to speak up and bring up the harder items to discuss. This will make your team stronger. Backlog Grooming – All team members should be involved as well as your PO. In Jira, I like to setup the sprints ahead of time – so I can see what work we have left. This is an easy way to check where the team is visually and how long before they will be done with an epic or milestone. In backlog grooming, the team should be reviewing all stories for the next sprint. This means these stories have a description, AC and story points. Any open questions are documented on the story and someone is taking an action item to get that answered prior to planning. Sprint Demo – This should include all team members, PO, business and anyone that the work affects. The team should prep prior to the demo. When I first start on a team, I make this a formal 30 min meeting to talk through what we will be demo’ing, who will be doing so, ect. As time goes on, the team should be able to self-organize and figure this out on their own. Daily Standup – Ensure the team is providing a valuable standup updated – what they worked on yesterday, what they are working on today and any impediments. I try to ensure this isn’t extremely technical, I want to understand what they have done and I want the PO to understand as well. I also use this time to ask questions as to why things are not moving – if a story is a 1 or 2 point story and its been 3-4-5 days, you should be inquiring as to why it is taking longer than what we thought. Encourage questions.
- As a user, I can ______ , so that I can _____ IMO this isn’t super helpful and it really takes teams down a rabbit hole. More time is spent trying to perfect this sentence than need be. As long as I can understand the description, being non-technical, I am happy with the story being viewed as complete.
- Acceptance Criteria should NOT include the following: Code review was done Non-blocker or major issues Performance testing performed Acceptance and functional testing done Acceptance Criteria should NOT include the above because The team should have a clear understanding of the Definition of Done and DoD should include Unit/integrated testing Ready for acceptance test Deployed on demo server Releasable
- Reasons to use pointing: Composed of integers – It’s a high-level estimate and there is no need for granularity Exponential – An exponential scale provides detail for small tasks and forces uncertainty for large tasks Forces you to choose more or less – the team is forced to make a choice and when faced with a larger task, there is no in-between. The sequence also allows the brain to intuitively distinguish between the numbers of the scale as different magnitudes. Non-Linear - 4 out of the 6 numbers used are prime numbers, reducing your ability to evenly break down or compare tasks. Large tasks are not squarely related to one another. This helps reduce over-analysis, or “analysis paralysis”. Always remember, its an ESTIMATE Ways to make estimation as accurate as possible: Collaborate with the Product Owner Good estimation gives the PO new insight to the level of effort of work and future work Questions arise about requirements and user stories and this helps the team understand the work and can help the PO prioritize all areas of work Agile estimation is a team sport Involving ALL team members is critical to estimating points Each team member brings a different perspective on the product and the work required to deliver a user story Start somewhere. Even if you are starting with 1 point = 1 day of work. To get everyone on the same page. Once you have completed a few sprints, you can then figure out velocity and continue to grow that way, but everyone needs to be pointing the same way. I like to have teams subtask stories – I am not a stickler, but I find that it really helps the team estimate the story points. If a story has 2 subtasks and is 3 or 5 points, something is off. If a story has 10 subtasks and is 2 or 3 points, something is off. This is helpful to me as a PM bc I can easily guide the team to talking through the stories and ensuring we are estimating the points as well as we can. My rule of thumb is no stories bigger than a 5. These stories, if carried over, will cause a major issue with burndown and velocity. I also find that it is easier to break bigger stories down into smaller stories that are easily achievable and closable in a sprint. Story pointing helps us set expectations. With this, we can identify trends and issues. We can have the conversations we need to have with our dev team or our client to make sure we are delivering what they expect but within reason.
- Yes, I said it. UNCLE BOB WAS WRONG! Metrics are important. Story pointing is important. All of the processes that Agile puts in place helps make your team better. Helps them understand their limits and set boundaries. Metrics help us set expectations with our clients. They help us build roadmaps and project milestones. Agile is flexible and all of these things are being constantly refined. That is what is supposed to happen. In no way shape or form is this going to be held over a teams head or is someone going to get fired because we didn’t meet our velocity or our commitments. But these things helps us have a conversation where we are informed and we make educated decisions based on the information we have. When I came onto to Carson, they were 2 small teams that were expanding into 4 medium sized teams. The team didn’t have a ton of structure around the Agile ceremonies and process. I came in and helped create that process and implement pointing on stories. Then came SAFE. SAFE is not my friend. Carson brought in a portfolio or program manager who was SAFE certified and expected us to run SAFE. It was a rocky first couple quarters doing so. We had to make some sacrifices on our end, but they did too. We can plan for a quarter of work – per SAFE – and effectively create a backlog based on the needs of the business. We can also use metrics sans velocity to plan properly for sprints and account for people’s personal lives – vacations, time off, sick days, etc. We are now running a pseudo SAFE type of project, but we are very much Agile in our day to day. There are a few things that I like about SAFE. We have epics, we tie stories to those epics. When we point those stories, we can track timelines to complete an epic. We can report on sprint metrics and epic metrics and the business can see truly how much work a feature or epic will take. For Carson, that was very eye opening – they figured out that these items aren’t easily implemented. You can’t just write a line of code to do what they are asking. It really helped start conversations on priority and MVP. That is why I am pro-metrics, story pointing and tracking these things.
- Definition of done means the feature has been developed, tested and meets all required acceptance tests. Done = the feature could be shipped to the customer The PO should accepts done features from the team at demo. Definition of done is a simple list of activities that add verifiable/demonstrable value to the product Writing code Coding comments Unit testing Integration testing Release notes Design documents Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities