MNAEG Gathering Thursday Sept. 15, 2016
RHunter
Tomo Lennox
On 2016-Aug-15, at 14:43 , RHunter <rodh...@usfamily.net> wrote:
Okay - a date set for a Fall gathering, so open for topics. The July thread left off with a few wanting to do something with Kanban ... that or anything else someone would like to lead on?Rod
--
You received this message because you are subscribed to the Google Groups "MN Agile Experiences Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mn-agile-experie...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RHunter
The Sept 15 evening gathering is confirmed so mark your calendar.
RHunter
Tomo Lennox has graciously volunteered to lead the discussion and is providing a list of “starter” topics (will be sent out soon).
If planning to come please indicate so on Doodle http://doodle.com/poll/uu6vb7r77avyust5 (note - it is not necessary to sign up to attend … just looking for an attendance estimate).
Sponsor TBD -
6 – 6:30 PM – networking, pizza
6:30 – 8 PM – Kanban
Gatherings are held at the University of St. Thomas, Murray Herrick room 206 (MHC206) - NOTE ROOM CHANGE.
See the MNAEG site for more details: https://sites.google.com/site/mnagileexperiences/
Here is a link to parking info http://www.stthomas.edu/parking/parkingoptions/
Note on parking: The Morrison ramp ($1/hr after 4 PM) is probably where most end up.
Street parking in non-permit areas on the campus perimeters can often be found (by those who enjoy the hunt).
RHunter
Discussion starters provided by Tomo - likely more than we would cover in 90 minutes! Review and come prepared to chime in on any you feel the desire to do so.
1) I like the Kanban board for showing the state of the stories in the sprint. But when I use the standard 3 questions at the daily standup, we didn't actually discuss the flow of the stories. On my last team, we walked the stories from right to left, with each person discussing the story they were working on. We also discussed dependencies, WIP limits and whether there was a different way of doing the work that could get a story to done faster. Is that a reasonable alternative to the standard standup?
2) When I started, the managers were still trying to track hours, so tasks had be attached to stories so that hours could be attached to the tasks. The tasks and hours took most of the time in sprint planning. After I could see that their story point assigned in backlog refinement were pretty good. I suggested they stop tracking hours and assign tasks, only if it helped them to validate the story points. This significantly improved the velocity, and improved the focus on getting the work done. The Scrum guide does not require tasking, is it only for messy stories and inexperienced teams?
3) We had to have rules” for moving stories on the Kanban board, and those evolved into a Definition Of Done for each column. This worked really well, but caused friction with people who only expected only one DoD. Does having multiple definitions violate any of the Agile principles?
4) When a bug was found in a story, we sometimes held the story in its current column (often a QA column) until the bug was fixed and the story could be moved to the right. But if the bug was big, we sometimes moved the story back to the left, and sometimes violated the WIP limits. Does anybody have a process that works more smoothly?
5) The natural flow of work typically took the stories across the columns on our Kanban board from left to right, but some stories skipped some of the columns, and some stories were more easily processed in an almost backwards order. We started tagging the cards so that we knew which columns were complete (and how did the work), so we would know which column hand to come next. This gave us more information than we could get from the columns. We kept the columns and let the story in the left most column that was not complete. Is there a better way?
6) We encouraged team members to learn multiple skills, so there several people who could pick up a story and do the next task. People with different skills would often put their tag on a task what had not come to them yet so that they could collaborate on it, forming a little team within the big team. Does this practice violate the WIP limit concept?
7) At the beginning of every sprint, the designers were overloaded and the testers were underloaded. At the end of the sprint, it was the other way around. Having testers try to “work ahead” at the beginning of a sprint was ofter inefficient. They had to guess at details and there was often test rework. We finally broke from Scrum and went full Kanban. We kept the 3 week sprint duration as a demo cadence, but deliborately planned carry-over work to start the next “sprint” running. We stopped guessing-ahead at work and tried to focus on WIP limits. Our velocity (story points per demo) went up, and the work satisfaction went up too. Is Kanban better than Scrum?
8) As we changed to full Kanban, There was no longer a need for sprint planning. We just added a refinement column and made sure there were always enough stories that were designed and ready to flow. The design meeting were often attended by most of the team, but after a while it took fewer people. We gained a small efficiency in the hours not spent in sprint planning for everyone and not in design for some people. This is certainly a violation of Scrum principles, but is it still Agile?
9) With no sprint planning, there was no sprint commitment, but we tracked story points completed per week. This was an even better metric than the normal velocity (finer grained), and it the teams worked hard to keep it up. They told me it felt better not to be forced to make a sprint commitment, but were still driven to be highly productive, Is there anything anti-Agile here?
10) It was not uncommon to need to rewrite a story, but in Scrum we would try never to change a story that was already part of the sprint commitment. The revised story would have to way until the current sprint completed and some portion of the next sprint was complete. This could be several weeks. When we switched to Kanban We would allow changes to any story that was not on the Kanban board, and we could agree to make it the next story we took off the backlog. This was usually a few days away, Is Kanban more agile than Scrum?
11) In Scrum, we often had only a small number of points left to fill in the sprint planning. If most of the stories at the top of the backlog were large, we would have to dig for a shorter story lower on the backlog to get the right number of points in the sprint.The Product Owner was often not happy with the stories we picked to fill the sprint. When we switched to Kanban, we almost always took stories from the very top of the backlog; there was not longer a reason to stories just for their size. Is this a weakness in Scrum?
RHunter
Reminder this Thursday, Sept. 15 is the next MNAEG Gathering (discussion topics around Kanban).
Kelly Weyrauch
321 Gang is offering the 2-day Leading SAFe course in Minneapolis, Nov 15-16.
http://321gang.com/2016/07/26/leading-safe/ <http://321gang.com/2016/07/26/leading-safe/>
Though I assume they teach the course like other instructors, 321 Gang has particular expertise in big systems that include software and hardware.
Kelly Weyrauch
www.AgileQualitySystems.com
763-688-0980