Rick Tonoli

Tag: scrum

  • Continuous Improvement

    Thinking about continuous improvement the other day I tried to figure out what makes a continuous improvement process work and what makes it stick, these are my thoughts:

    • It should be a slow, gradual process of change, no “sudden movements”.
    • It should be a continuous flow of change, no settling down into a rut.
    • It should be a culture, not a bunch of individuals with ideas.
    • It should be unanimously accepted.
    • It should be measurable.
    • It should be celebrated.
    • It should be evangelized.
    • There should be room for failure, and for success.
    • It should be rewarded.
    • It should be encouraged.
    • It should become default behaviour.
    • It should be transparent.

    What else?

     

  • Velocity for the layman

    WARNING:This is a brain dump of an idea I’ve been playing around with, some confusion may occur!

    As a ScrumMaster I often struggle to explain the concept of velocity to people, a critical concept to grasp to understand how to report on progress and capability. I often get these questions thrown at me:

    • How many features can we complete in X weeks? or…
    • How many bugs can one developer fix per day ?
    The danger of these questions, for me, is not so much in the question (which doesn’t make sense) but in what happens afterwards:
    • 1 developer = 1 story per sprint so 2 developers = 2 stories per sprint, right?
    • 1 developer can fix one bug in 1 day, we could double our rate by doubling our people!! or…
     So, to the challenge: how to explain the danger is making all pieces of work equal and how to explain the benefits and logical sense of measuring in velocity.
    Let’s start with the analogy: You’re going on holiday, you need to travel from city A to city B (your goal) with 5 stops between.
    Doing it wrong would be to assume that you multiply the time to the first stop by the number of remaining stops and that would be your final travelling time.
    Doing it right would be to look at the distance between each stop, calculate the average speed you can maintain, and then add up the travel time between each stop. Even better would be to:
    • Adapt your average speed based on environmental conditions. Bad weather, day/night travelling, fatigue, additional rest stops, travelling through mountains? These all affect your average speed.
    • Keep track of your average speed as you travel, this should give you an indicator of exactly what average you can maintain.
    • Check what affects the distance between towns like road closures, alternate routes.
    • Be ready to adapt to changing conditions, like accidents and sudden road closures.

    Given the above you should be able to accurately predict when you will arrive at your goal. As a bonus you can also work backwards. Given your need to arrive at a particular time, you can sum up the total distance and divide it by the time you have and this should give you the speed you should try to average.

    So, to bring it back to velocity, you average travel time can be equated to the teams average velocity (or capability). Stops are user stories/bugs and distance between cities is the effort of doing the story. Conditions of road, road closures, mountain travelling, predicted bad weather etc is your complexity.

    Here’s hoping this analogy makes sense, if it doesn’t please let me know. I still think it’s missing something though so I may add to it at some point…

  • Change is good

    I’m often amazed at the number of dogmatic “prophets” out there when it comes to the latest fad’s of agile development. I myself am about getting productive and like to take the best of ALL worlds; change is not only inevitable but necessary, even changing of a process BUT, only if the change leads to improvement! I believe a process of continual introspection and change by a team, combined with a good way of measuring the effect of that change,  is essential for good team performance.

    That in mind we made the following changes to the way we practice scrum:

    1. We added a default story to cover recovering technical debt (or refactoring if you will) in that story. Essentially we assign a “story point cap” to this story (say 5 points) that’s based on our current velocity and duration of sprint. We then assign “technical debt recovery” tasks to this story until the team feels there are enough tasks to fill the story points. I know, sounds like the wagon pushing the horse but it’s something we’re trying that other teams have used effectively.
    2. We’ve started estimating (wait for it…) HOURS on tasks. Stories are still broken into story points but the tasks are estimated in “hour blocks” (2, 4, 8, 16) as they are put up. The purpose of this is to act as a type of “sanity check” for story point estimation. An added benefit I found was that the team members seemed to think a lot more about a task when they had to assign time to it.
    3. We’ve started using a round table instead of the tradition square meeting tables. I found this very effective in encouraging participation and collaboration.
    4. Story point estimation was done using a technique I learned on training that speeds up the estimation incredibly (works well with lots of stories). This is how it works (well, how we did it anyway):
      1. All the stories are explained to the team and placed in a pile on the table.
      2. A wall/board is divided into sections, each representing a story amount (we used 1, 3, 5, 8, 13, 20, 40, 100).
      3. Each team member takes a pile of cards and sticks them in the column(s) they believe it belongs, no-one talks or interacts other than with the product owner to understand the story further.
      4. If a team member disagrees with where a card is, he/she simply moves it to where he believes it SHOULD be.
      5. This carries on until all the tasks are done. Remember, the key is NO COMMUNICATION between team members during this process, this has the effect of forcing people to think about why someone made a decision to place something in a particular column, or why they’re moving it.
    5. We’ve started experimenting with TDD and Paired Programming, which seems to be going well.

    One additional thing I’m toying with is moving to a more Kanban based board, the team has problems with taking on too much work and I think creating a way of limiting the pulling of work will work.

    Finally on how to measure if these changes are effective, well, to be honest I’m not entirely sure. I think the best way is simply to see if the team becomes better at actually doing what they predict they can do while maintaining a sustainable pace and having fun; other than that I guess we wait and see…

    I’d be interested to know what kind of changes you brought about in your team and the effect of them (both good and bad), let me know…

  • The chatty daily standup…

    One of the “ceremonies” of Scrum (man that sounds so culty) is the “Daily Standup”, a daily planning meeting where teams realign and coordinate their efforts for the upcoming day. It’s a concise, no frills no fluff zero waste of time meeting that answers three questions: what have I done, what am I doing and what are my issues, and is generally over quite quickly…but what if it isn’t, what if it degenerates into a technical discussion about the implementation of widget-x or how the build script is not building something correctly or which framework to use to solve some problem…

    I’ve found this to happen quite often and all too often I see people coming down on the team with statements like “cut the meeting off at 15 min” and “remind the team to stick to the 3 questions”… all good advice but you’re fixing the wrong problem. I believe this behavior to be an indicator of a dysfunction within the team itself. In a truly collaborative environment teams should be discussing and solving problems constantly and not just at certain points through the sprint (like the daily stand up). If they’re only collaborating around the daily stand up then something is wrong and the team has a dysfunction preventing constant collaboration…

  • My questions on agile processes

    Something I have found very interesting in today’s “agile environments” is the adoption of processes.

    I’m caught in an endless loop on my thoughts around the place of processes and how they should fit in a team.

    Generally processes are put in place in order to protect the team, sort of like a safety net.  Given this chain of thought people should be interested in following the process, and should try following processes as close as possible. At the end of the day, Its almost like wearing a safety belt.

    This is where it gets tricky though, in many cases developers, testers or any other team members may not not see the need for this process, they may believe it is more of an impediment than anything else.

    How should this be dealt with ?

    Should the team be wholly responsible for the decision to keep or lose the process ?

    Should the team be educated every time a process is put in place ? ( Its too often I have noticed that people simply follow processes mindlessly)

    In true scrum nature it suggests that the team make these decisions. What if some of these processes have been put in place by parties outside of the team ? Furthermore  these parties that may have a good understanding for the need of the processes ?

    So I go back to my safety belt analogy, sure its a pain to put it on, but if you are unlucky enough to be involved in an accident I can assure you that you will wish you had been wearing it. Unfortunately in scenarios like this it seems its only when its to late when one may value the process ?

    Another question  I have is around how often should the necessity of a process be revisited ? Is agile not about constant improvement, about constantly looking at what went well and what could have been done better ?

    Here is my take, but please add comments im really excited to hear other opinions on this…

    I believe that  processes should be revisited constantly, possibly with each scrum retrospective, its important to remember when doing this to consider the impact of failing to implemt and follow the process.

    If the process is enforced by external party, and you feel that you dont see the need for it, discuss this with the party responsible and try to understand why it is they deem the process necessary, it may turn out that you have already covered the risk that this very process is trying to prevent. After all is this not what scrum is all about ? COMMUNICATION ?

  • Why do we do what we do?

    I thought of doing a few short posts on the why’s of agile and specifically scrum. Product owners are driven by ROI, so why should we not adopt the same attitude regarding the various “ceremonies” and practices we adopt in our day to day agile development lives… why do I do <something> and what is the benefit of doing it?.

    I think it’s important that people understand the rationale behind doing something (like time-boxing for example) before simply adopting it, unless, of course, you like the idea of arranged marriages 😉

    Here’s a couple of starters I’ll try cover:

    • Why is it important that the team decides what work should get done?
    • Why do scrum “by the book” first, and then change it?
    • Why do we time-box?
    • Why are the roles, and the clear separation of roles, so important in scrum?
    • Why have a retrospective?
    • Why demo?
    • Why use a physical scrum board?
    • Why should the team run the scrum board?
    • Why use a tool to help you run your project?
    • Why the daily stand-ups?

    and others …

    Feel free to give me some answers, but I’m not really interested in someone else telling me the answers. This is more of a personal journey of discovery so that I myself can understand why I do what I do, and yes, the answers may not be perfect, but every great journey must start with a first step…

  • A new challenge…

    Today is my 3rd day as an official ScrumMaster. Although the first 2 days were, well, daunting at best, today there seems to be a bit more clarity. The challenges here are similar, but still different. Resistance to adoption is coming from a different place this time. The teams seem to want to do Scrum (at least it appears that way), although there is ALOT of area for improvement. There is some frustration from management and this is starting to flow over into the teams and cause people to disbelieve the effectiveness of an agile approach (I guess it’s a classis “blame the tool” scenario). I think the frustration comes from the misdirection that exists in the way the teams are applying Scrum. Off the top of my head and based on a few days of observation the following are big issues that need to be addressed:

    • There is no visible prioritized product backlog with no obvious release plan (I believe this is where the main frustration comes from)
    • The teams have no burn down charts, they seem to be relying on the tool (Version One) for this, but without the discipline of keeping it up to date, it’s not really useful. Another reason why I don’t really like tools, people place too much reliance on it and fail to realize that it’s not using the tool that’s important but rather that something actually gets done.
    • There is a need (and lack of) a Scrum of Scrums to co-ordinate the effort between the teams.
    • The daily stand-ups are not focused co-ordination meetings and often break down into general discussions, sometimes “chickens” even take control of the show.
    • The impediment lists aren’t being managed (and aren’t prioritized)

    There are other smaller places of possible improvement, but we will need to fix the larger issues first.

    Overall I’m a mixture of excited, confused and nervous about the next few days. Where I had the advantage of already having earned the respect of the previous companies team I now find myself sitting with the the daunting task of having to re-earn respect. I do not believe in telling people what to do but rather in having them do things because they feel it is the right thing to do, for that to happen people have to respect you and your opinion and believe in you. Until that comes I will fall back to process and hopefully the respect will come when my opinion creates value for the team(s).

    Let’s see how things go…

  • My First Scrum Board…

    This was my first attempt at a usable scrum board. There are some flaws, like the blank story card in the Product Backlog?! (only noticed this now, no idea how that got there, will have to find out) and the fact that there’s a story that has no tasks assigned to it yet is not in the DONE area. I think it worked pretty effectively, especially the use of colored post-it’s to represent different “types” of tasks (tests, bugs, impediments etc.). I say this because I was able to pull in random people (business) and ask them if they understand what is going on here, and, with some basic explanation of the process, they understood perfectly. For me a true test of an “information radiator” is if a stranger can look at it and, given the basics, understands it reasonable well.

    Some things that I’d like to add include the teams definition of “DONE” and perhaps the three questions to encourage people to focus on the purpose of the daily scrums.

    First Scrum Board

     

     

     

     

     

     

     

     

     

    Thoughts or ideas on improvement (or something I’m missing)?

    The bottom left stack of post-its are what we classified as “production issues” directly affecting business, which the team chose to tackle as they came in. The result was that it clearly shows we have a problem with existing systems (the sheer number of critical “issues” the team had to deal with).

  • Change…

    The new year will bring a plethora of change in my life, a new company, new goals, new challenges, new ideas. I must admit I’m eagerly looking forward to this much like a new astronaut looks forward to his first space flight, nervous excitement I guess would summarize it.

    Along with this I’m also a little sad about leaving my current employer. I’ve been instrumental in growing Scrum to where it is at the moment and I have to say that, although there is still alot of room for improvement, it’s just reaching a point of “proving itself” and getting it’s feet, and now I’m leaving. Lets hope the passion I tried to push it with rubbed off and that it will continue to improve on itself and a new champion will step up to fill the gap. The team(s) I worked with have reached a point now where they are reasonably self organized, so there will be no problem there. I think the possible impediments to continued growth of Scrum will be:

    • The lack of a strong ScrumMaster/Coach to protect the team(s) and nurture the process.
    • Inteference from management due to “command and control” culture.
    • Breakup of the existing team(s). Although this may prove useful because they may end up “infusing” the other team members.
    • The warping of the process in order to hide problems.

    I’ll have to come around here in a few months to see how things are running…

  • A journey…

    As I delve deeper and deeper into “Scrum” and read more and more blogs / papers on the subject I keep fixating on the same question… “What does it mean to be a ‘ScrumMaster’?”.  Yes, I know there are the standard “definitions” of it but I think it’s more than that. Personally I equate it to a journey, a kind of never-ending journey of improvement, both to self and to everyone you touch. I do not think it is a methodology, I do not believe it is even a process, I simply believe it is a set of guidelines that set you on the path to greater understanding and improvement.

    My own personal journey has been interesting, and I’m sure will be for a long time to come. I started off thinking Scrum was “the silver bullet” that will solve all problems, but the more I read and the more I try to apply it the more I realize it is not a solution, it is merely a way to find a solution, and that almost every day the more I practice it and the more I experience it the more I realize that it’s core purpose is actually to expose places of improvement!

    Along these lines I believe that the job of a “ScrumMaster” is to improve the world around you to a point where you become obsolete, so, the act of becoming a “Master” of “Scrum” is the act of mastering the art of exposing areas of improvement and acting on these immediately and to the best of your ability, and then taking the results of this and feeding it back into this continuous loop of inspect and improve.

    Following this I think (some of) the greatest strengths of a “ScrumMaster” are:

    • To truly observe and listen, without interfering.
    • To act without hesitation, but with a certainty based on knowledge backed by experience.

    I welcome any thoughts on this, am I wrong? Am I at close?