www.agilean.dk

Scrum updated (2013) including my humble experience as an add-on.

I’ve written a summery post about Scrum update 2013 including my experience and advice. It’s been a while since I ever have posted anything about Scrum but two events have inspired me to do so. First I went to a private dinner with Jeff Sutherland last year since he is a friend of Systematic. I discovered that once getting to know Jeff he is truly an amazing man and he has had lot of experience! Then this year I attended his talk or Q&A at Agile 2013 Conference regarding the Scrum 2013 update where Jeff just without prep answered question about the update that Kenn Schwaber and Jeff just published. Then I thought that my own experience with scrum is similar but also kind of different and want to share this experience with you. So here goes J
Scrum itself is based on 3 pillars and 2 of them are Inspection and Adaptation (the last one is Transparency). Now learning about scrum is not what this post is about but below I’ve drafted out the 6 changes made to the Scrum 2011 version into this Scrum 2013 version and in addition to this I’ve ADD MY EXPERIENCE as a comment which is experience (empiric learning) and offered as an add-on for you to use J
The 6 areas that are updated in Scrum 2013
1. Artifact Transparency
2. Sprint Planning / goal
3. Product Backlog
4. Time boxed events
5. Daily scrum or planning event
6. Value
1. Artifact Transparency
If thing is not visualized bad decisions can be made, so make your artifacts visible like Product Backlog, Scrumboard (sprint backlog), Burndown Chart, Release Board, User stories, Test scenarios , Performance analysis and more or you increase your risks and value may diminish!
ADD MY EXPERIENCE: Transparency of how clear the scope is for the next sprint is a great metric to measure and sharpen your “Readyness” of the team’s ability to secure grooming is done before sprint start.
ADD MY EXPERIENCE: All teams should be using posters, paper on the wall for the scrumboard and a product backlog on the wall too. It should be tangible so we can fell the way we work, standing up, moving posters with our own hands and prioritizing the backlog by moving posters up and down. In fact, everything should be on the wall and nothing should be in an application. Well, I know that this is not going to happen due to several facts, like small space, extended / dispersed teams or like. If possible do like above – if not, try to make as much visible by setting up monitors that are showing the stats places where everybody sees it, in the hall way or like.
2. Sprint Planning / goal
Use as much time as you need and focus on the sprint goal. This is often 2 hour per week your sprint is. So a 2 weeks Sprint Planning meeting should be 4 hours maximum.
The target for the sprint planning is to set up “The sprint goal” which the all tasks should be the fundament for.  
ADD MY EXPERIENCE: As we in the end of the Planning meeting forecast the items of the sprint backlog II strongly suggest to follow the recommendation provided by the Scrum Guide “Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.”. I believe decomposing the User stories into tasks of 1 day or less forces cognitive thinking about the forthcoming  work and flosses out risks (the subconscious known risks which is yet not spoken out). This will affect the teams view on the “Sprint Readness” before commitment to sprint scope.
3. Product Backlog
“The Product Backlog is refined rather than groomed. The refined Product Backlog items are transparent, well enough understood and granular enough to be input for the Sprint Planning and for selection for the Sprint. Product Backlog items with this transparency are called “Ready.” Ready and Done are two states that reinforce transparency.”
ADD MY EXPERIENCE: The difference between “refined” vs. “Groomed” I do not understand so I like to explain what my experience is and I’ll call it Grooming. Doing Grooming in two steps as a pre-burning event is very powerful.
A.) P.O. Grooming :
First of all, a user story or a creative process is running within the product development process which the scrum framework doesn’t include (which is a good thing). Well the business need to groom any new idea and as it evolves this needs to be written into a user story and elaborated (I call this P.O. grooming or Business grooming). Now the P.O. is ready to prioritize the continuously evolving product backlog and now the developers are add (a developer could be taken into advice earlier).
B.) Technical Grooming:
Often the developers meets the product backlog items for the first time at a Sprint planning event, but I like to schedule a 2 hours of technical grooming session for each week of sprint as a pre-burn to the sprint planning. This has some advantages and few disadvantages.
One of the advantages is that developers are being presented of the product backlog items before sprint planning they are able to have time to think about how to work out the technical specification. This fits at least 2/3 of all developers personality they rather think before speaking out they mind of something new they just has been presented to (Introverts).

C.) Sub-Grooming:
Another advantage is the ability to do sub-grooming. Sub-grooming is done by 1 (max. 2) developer working with a POC or just investigating a technical hunch to solve an issue. The sub-grooming result is presented at technical grooming session for the rest of the team. Now it is possible to do experiments and investigation before deciding on the sprint planning meeting what to include in the scope. This will reduce the technical risk of these items. 
Doing technical grooming and sub-grooming as a pre-burn to the Sprint Planning meeting reduces meeting time of the Sprint Planning Meeting” as all the team need to focus on is the sprint goal (presented by the P.O. as a business goal) and the work the team will committing to for reaching this Sprint goal. Now it there are less variables at the meeting and it is easier to secure that our scope is “Sprint Readiness” = 100%.
Well, the disadvantage I can see is that we now have the possibility of task switching as we have to plan and execute one extra meeting a week. True. I just like to add that the price of not having a ready sprints scope is mostly not meeting the sprint goal – so I still recommend this way of working because I’ll seen it work in many different teams and companies.
  
4. Time boxed events
All meetings are time-boxed and executed in a manner that the purpose of these events are meet within the time-box as we are preventing waste.
ADD MY EXPERIENCE: Time-box with having the pomodora technic in mind. I suggest the following time-boxing
  • Sprint durance 2 weeks (first day Wednesday week 1. until Tuesday week 2.)
  • Daily scrum 15 min. every day and it is best when done in the morning between 9.00 am and 9.30 am
  • Sprint planning 1 hour Wednesday morning and followed by a Daily stand-up
  • Technical grooming in 2 hours once a week (Friday morning or afternoon is good choices)
  • P.O. Grooming is not a meeting within the team but P.O. Grooming involving developer feedback should be done with in max of 2 times 25 min with a 5 min. break (55 min.) once in a sprint.
  • Sprint review in 30 min. divided into 15 min. for demo and 15 min. of feedback from the guests. It must be held Tuesday just before lunch or just after lunch in week 2.
  • Retrospective 2 hours (see my blog on how to conduct retrospectives)

Other meetings that the corporation needs the team to attend to are often forgotten to include in team planning!

  • Daily project brief max 10 min.
  • Weekly department brief max 30 min.
  • Monthly company brief max 1 hour
  • Attending courses and conferences which be subtracted from the sprint velocit

The next 4 bullets are difficult to plan but experience helps a bit and experience within the team helps a lot. Earlier sprints preforms knowledge which you can apply common sense and reserve time for these unexpected event within the next sprint as having time-box “tasks” or “posters” with the time of ½ or 1 days’ work that can be used for such unplanned events. Remember to use different colors for the different type of tasks on the board so you easily flag out these unplanned events – helping transparency.
  • Attending job interviews is a joker but it not very often this is the case
  • Attending workshops with creative, business or architectural ones
  • Support other projects
  • Support operations

Questions still need answers!
  • What to do in virtual teams?

If we don’t meet on a regular basis at the coffee machine or in the cantina how can we get to know each other and get empathy, understanding and trust?
  • How to handle teams with different personalities and/or cultures?

Like Latin America girls often need to small talk like 5-10 min. in the start of the meeting before they will decide anything. Accountants hates small talk! Sales people is only doing small talk! Introverts is not participating in a workshop and so forth. These different personalities and cultures makes it hard to set up a template for meetings and workshops removing all “Waste”. You need to take these aspects into account.
I like to hear your comments on these questions? What are your experience?
5. Daily scrum as a daily planning event
The team must Re-enforcing the Daily Scrum as the daily planning event. Don’t use the daily scrum for status rapport.   Therefore the questions are changed.
a. What did I do yesterday that helped the Development Team meet the Sprint Goal?
b. What will I do today to help the Development Team meet the Sprint Goal?
c. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
ADD MY EXPERIENCE: I like the questions to be different prioritized. First things first. What is the most important thing to know?
The 3 daily questions:
A. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
                B. What will I do today to help the Development Team meet the Sprint Goal?
C. What did I do to meet the team to reach the team sprint goal? (And If I didn’t do anything yesterday to help the Development Team meet the Sprint Goal – don’t share)
6. Value
Focus on the value that the team delivers

ADD MY EXPERIENCE:
Value provided for the users is absolute the only thing that matters. No matter how fast your database run, how well your test are executed or how fast the code is transferred over the wire to the customer matters at all. What matters is the customer experience and the value the Customer gain from the solution. That’s way we sometimes have to compromise great craftsmanship for reaching a window of opportunity. I really like to set up the plan so that we deliver smaller trunks and then deliver often.

At e-conomic we made a team deliver improvements to the running application once every 14 days (called Marked Packets) which increased the value for our Customers incrementally – This is truly a great way to work due to all the positive feedback from the customers and the ability to adapt to any wishes spoken. 



Sources
Kenn Schwaber and Jeff Sutherland present this new updated guide
At Agile 2013 in Nashville Jeff Sutherland answer questions regarding this new updated guide. I’ve taped most of the session and share it on Google Drive. Sorry about the sound quality I hope you can understand it anyway. It was taped in a big conference hall with some kind of echo.

1. https://drive.google.com/file/d/0By7RGeHx3vR9NXhVSXA4RnVVZVU/edit?usp=sharing
2. https://drive.google.com/file/d/0By7RGeHx3vR9RkZ6Y3ZUQWNLcmM/edit?usp=sharing
3. https://drive.google.com/file/d/0By7RGeHx3vR9a1hXcVNEaTB3Q2c/edit?usp=sharing
4. https://drive.google.com/file/d/0By7RGeHx3vR9dHE4ZVlTc056UFk/edit?usp=sharing
5. https://drive.google.com/file/d/0By7RGeHx3vR9eHlZQzV2MUtmU2c/edit?usp=sharing

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>