Change Starts From The Beginning

Zan Change , ,

In a conversation with a fellow Scrum Master recently, my mind spit out a phrase that I thought was actually quite good: “Change doesn’t happen from the rear, nor the top or bottom. Change starts from the beginning.”  It was sort of off the cuff, but I really rather liked it, and it inspired me to write a little bit more about the statement.

Getting “Work” Done

This phrase came about based on some feedback I was receiving about a different conversation, in which I’d talked about the putting problems and/or objectives into a product backlog, as opposed to “work”, a.k.a. the actual tasks team members will be undertaking.  Many teams and organizations transitioning to Agile experience a phase where, not understanding any different, they map their old mindsets to new practices. Unchecked, we call this “Lipstick on a pig”: fancy window dressing on old concepts.

A particularly damaging instance of this is taking everything a current team is doing, of course formatted in a task list or something similar, and declaring that the team’s Product Backlog. After all, the Scrum Guide says “The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases”, and that sounds just like the current task list, work breakdown structure, or Gantt chart we already have right? Score! Mark one off the list. Yes, except… well, no.

In many (most?) cases, an Agile Coach or Scrum Master will advise you that your product backlog should stop short of listing the tasks a team will take on. There are many reasons for this, all of them valid:

  • Many Product Owners will not have a deep understanding of the value delivered by a given task.
  • Product Owners are not responsible for determining how we deliver value, just ensuring that we are doing our best to maximize the value the team delivers.
  • Individual tasks may only be part of a vertical slice of functionality, which doesn’t constitute a “Potentially Shippable Increment”.
  • Task lists have even less meaning or value for external stakeholders.
  • Tasks generally represent a solution (or part of one), and solutions don’t generate nearly as much conversation or problem solving effort as, well, problems or questions.

I’m sure if I thought about it longer, I could come up with more, but I hope you get the idea. The point is that just cutting and pasting your current task list doesn’t constitute making a product backlog.

Starting at the Beginning

You may ask, “OK, but we’ve re-formed the teams, moved people around and we’re doing all of those darned ceremonies Scrum ‘forces’ on us… this isn’t really that big of a deal, right?” After all, we can inspect, adapt and use Scrum in all its glory. I would challenge, though, that true change must come from the beginning, and I see no more natural “beginning” in Scrum than the Product Backlog. On just about any representation of Scrum (or just about any other flavor of Agile), the Product Backlog will be the beginning of the flow. And if you pour garbage into the head waters of a river, you will pollute the entire stream.

There’s always commentary on whether a change to Agile needs to come from the “Top” (management) or the “Bottom” (teams and developers), but if you want to achieve success in such a major upheaval as an Agile Transformation, you need everyone to be part of the change, and even people outside of your traditional IT/Engineering structure. These are your stakeholders, and keeping with the river analogy, they’re floating right along with us.

The very nature of our conversations need to change. Change the backlog, change the conversation, and by its very nature you’ll change the way things are done.  Trying to change the way things are done in order to change the conversation is like swimming upstream: you can get there, but it can be MUCH harder.

Next Time: What Does Changing the Product Backlog Look Like?

I am going to give some time for this concept to sink in for a bit. In my next post, I’ll talk about some tactics and techniques for changing how we represent our Product Backlog, and the necessary changes that are required to make that happen. At some point, I’ll also cover some of the results you may find by changing how we talk about “work”, both obvious and subtle.

Thanks for reading! As always, I welcome your feedback, questions, thoughts and concerns.

Advertisement

Manifesto for Agile Line Managers

Zan Uncategorized

Managers? There’s no Managers in Scrum!

Its true the Scrum Guide makes no provisions for Managers, and really in single team Scrum (in a vacuum) there isn’t a need for a manager at all. However, the reality of most situations is that there will be management around any given Scrum team. Most Scrum teams are transformations in traditional organizations, which comes with management. Most organizations still require someone with the title of “Manager” to handle HR tasks like hiring and firing, approving time off, doing wage adjustments, etc. In certain scaling frameworks, this is even recognized and suggestions are made to ensure teams are able to self-organize and take control of what they do.

In LeSS, this is the concept of the “Line Manager”. They suggest a 100-to-1 ratio for each line manager, with the thinking that if a Line Manager has that many people to support, they will be too busy to interfere in the day to day operations of teams.  However, this doesn’t always happen over night (or at all), and managers may have the time and capability to be involved with team operations. In Agile, we recognize that many “traditional” management activities in Waterfall actually can be detrimental to a Scrum team.

OK, but a Manifesto?

I’ve recently been thinking quite a lot about the line manager, and how to help “command & control”-aholics kick the habit and act in a manner that will help uplift and grow teams. I did some google searches, and looked through various other sources, but I didn’t see anything that I liked, that I could provide to a line manager to use as I personally use the Agile Manifesto; something which helps codify where value is found, and what principles I believe lead to effectiveness.

So, I did what most people would: I created my own. I cribbed off of the Agile Manifesto, and came up with my own “Manifesto for Agile Line Managers”.  Now, I’m not a line manager, so I expect I probably got it wrong. I hope, having been in positions of authority, and having coached people in those positions, I’m not too far off.

I would have preferred to have taken a bunch of successful Agile Line Managers up to Snowbird, Utah and locked them in a room for a few days to come up with it, but A) I don’t have that kind of money or time, and B) I don’t know that many successful Agile Line Managers.  So I look to the community. I will cast out what I have created, hoping it sparks discussion, or at least one or two people find it useful.

All right then, let’s have it!

OK, here goes:

Manifesto for Agile Line Managers

We learn and discover better ways to allow teams to develop software in line with the Agile Manifesto for Software Development. We therefore have come to value:

Enabling Learning over Enforcing Rules

Empowering Teams over Insuring Delivery

Providing Vision over Delivering Directives

Taking Measured Risk over Avoiding Failure

While we can have success and find value in ideas on the right, we believe the ideas on the left will lead to greater overall success.

Principles behind Agile Line Management

Our highest priority is to enable Agile teams to deliver valuable software early and often.

We welcome changes to processes and rules, even long-standing ones. Agile teams learn by doing, and we must harness this change for the good of the organization.

Act quickly on required changes. Items which disempower teams will quickly cause loss of motivation and flow.

Managers and teams must collaborate to solve issues in ways that are both effective and understood.

Allow motivated individuals to form teams to deliver great results. Give them the environment and support they need, and trust them to get the job done.

The most effective method of communication is in person. Face to face communication and highly visible physical artifacts promote and enhance transparency and trust.

High functioning teams delivering working software is the primary measure of effectiveness of an Agile Line Manager.

Agile Line Managers enable sustainable development, through enabling learning and empowering teams to set a constant pace balancing growth, development and support.

Agile Line Managers allow teams to exercise technical excellence, and provide teams with the ability and support to continue to improve technical skills to enhance team Agility.

Simplicity in Management is essential to self-organization. Always apply the least amount of authority possible, with a bias towards empowerment and encouraging learning.

The best teams, rules, and procedures emerge in self-organizing organizations.

At regular intervals, Agile Line Management teams review their effectiveness, and reflect on the results of their actions, then use this reflection to adjust and tune behavior and technique.

That’s it?

That’s it. It’s not a replacement for the Agile Manifesto, rather and enhancement and refocusing of ideas towards Managers (or others with positional authority) working with Agile teams. I welcome your feedback, and hope it may be found useful by someone.  It’s probably not the last iteration of this idea either, I’m just one person, but maybe it gets people talking, and maybe as a community we come up with something great.

I’ll put image versions below. Please feel free to iterate on them, and share as you see fit.

LineManagerManifesto

PrinciplesBehindLineManagement

What Charity Showed Me About Flow

Zan Process Flow, Team Dynamics , , ,

The other day, I participated in a charity event for Feed My Starving Children. This post is not to show how good of a person I am, for one does not do charity for recognition’s sake (the actual act of charity is reward enough). However, before I talk about some of the things that struck me as I was participating, I’d like to note that FMSC is a very worthy organization, worthy of one’s time, and if you see fit, worthy of one’s donation.

A FMSC event, at least as I have seen, is organized thus: they come in and take over an organization’s large room, and fill it with packing stations. At these stations, teams of around 10 (not sure on exact number) work together to measure out an amount of various ingredients, which make up a single meal, into a bag. The bags are then sealed, boxed, and sent to be placed on pallets, loaded up and shipped out. Folks participate in a two hour shift. They do a brief training before, and a brief after action review. Super high level view, but I think you get the idea. Here’s one of their videos, if you’d like to see some in action.

During my particular shift, I was working “Warehouse”, which is designation for the folks who support the table crews. I thought, firstly, that it might require less attention and activity than a packing table job (I was wrong!!). I also thought it would be interesting to see the flow of activity from place to place (I was right!). I was also joining a buddy of mine, who had worked the previous shift (his wife helps organize this whole event through the church of which they are a part, so shout out to Alicia and Journey of Faith church in Redondo Beach) doing this job by himself, for the most part.  It didn’t sound too difficult, however, we expected higher volume this shift due to crew makeup (more adults), and so we had a third gentleman as a member of our little logistics crew.

The finishing table consists of weighing each box as one of the “runners” delivered it to us, to ensure it was in the acceptable weight range (and therefore correctly packed based on quality controls no doubt done at the filling stations), sealing the boxes, marking the date and shift, and loading them onto a pallet. Once a pallet was fully loaded, another crew took our product and finished it for shipping. We quickly decided on roles, I would weigh and verify the boxes as they came in, my friend would settle and seal the boxes tightly, and the third member would mark the boxes once sealed, and load them onto the pallet.

Off goes the horn, and away we go. We have a bit of lag time at the beginning, as the teams begin to get their bearings and begin production. As the first few boxes begin to arrive to us, our flow works well, and the first few boxes go off without a hitch. However, the teams are now getting their stride, and runners are bringing full boxes more quickly. We run into our first issue, when multiple runners arrive at the same time. Only one box can be weighed at a time, so the runners dropped the boxes and moved on to the next. Unfortunately, the input and output stream get mixed, and we have no way to tell which boxes have been already weighed. Therefore, I needed to reweigh a few to ensure they were all correct, and none were missed. Quickly, we shifted, and I grabbed a marker, figuring that if I marked shift and time as I verified boxes complete, then we would know what can be sealed without me having to watch.  We powered through our bottle neck, and got back on track. In a lull between some boxes, we discussed the change as a team, so we all knew how boxes were shown as verified. Yay, problem solved!

We kept ticking, and fillers kept filling. We were receiving boxes from one a few at a time (which would be a great study on asynchronous delivery, but I will try to stay just where I was for now), but our process held up, and we were processing items through pretty well, continuing flow. That is, until there was an issue with one of the pallets that we had already finished, and my buddy had to pull off to help get that fixed. While we adjusted, and worked the best we could, this had multiple effects. For example, we’d suddenly lost a large portion of our processing ability, and we both had to fill in his role, while still trying to do our part, which from positioning was inefficient. Our team was too small to handle losing a member, and our process too tightly coupled. Due to this, we developed a bottleneck nearly immediately. Since work was piling up in the center of our process, when I went to help with that, work began to pile up at the beginning of our queue. This also had an effect the efficiency of the runners, as we were not as prepared to accept work from them. My friend was only away for about 5 minutes, but we had piled up about 7 boxes into our bottleneck by the time he’d returned. When he returned, we still had items mid process, and it took us about 15 more minutes to clear out our bottleneck and get back to a state of flow, where we were processing input as it arrived (about 3 times as long as he was gone!).  From this, we learned that if someone stepped off for an issue or a break, we had a member of the support crew (who could fill any role, as they were from FMSC) fill in. They may not have been as efficient, as they had to adapt to our flow, but it helped avoid major bottlenecks.

There were other various instances of inspect and adapt during the process, that I was aware of: reordering the table gave a visual indication of flow direction (improving the experience for the runners, and limiting mixing of processed and unprocessed data), orienting the boxes in the same direction as they came of the scale (facilitating both verification marking and sealing), and improvements on preparations for pallets (facilitating removal of completed work, and preparations for the next load). All of this, in a single two hour session.

A few key takeaways:

  • Don’t wait for a retrospective to inspect and adapt. Constantly be looking for ways to improve, and experiment (but make sure your team is aware!)
  • Achieving system flow is more important than achieving local optimization. Any improvements I make to my process are for naught if they negatively effect other parts of the flow.
  • Losing team members to “special projects” hurts the individual and the team. The individual loses connection, and the team may not have the skill or work ability to replace. The effects are far reaching, and a small gain at one point can cause a much greater loss elsewhere. If it’s good enough for one of us, it’s good enough for all of us; if it’s not good enough for all of us, it’s not good enough for any of us.
  • If the world was perfect, we’d all have exactly enough work to keep us busy without over loading. The world is not perfect. Flow is hampered when there is more work then can be done in a given period. Overloading a part of the process flow has far reaching effects before and after the single point. It is therefore better to do less than is possible, then to try to do more (when it can be set up that way!).
  • Above all, doing something for someone else is an uplifting experience. The rising tide raises all boats, so elevate someone else to elevate yourself. It feels good, and who knows what you might learn!

Our shift, by the way, was at that time the most productive shift of the event at the time. It was more than double of the previous shift my friend had done. We had no major issues, and everything went off pretty well. Past experiences can sometimes prep us for the future, but always remember that something may just come and blow your expectations away.

Once again, FMSC is a great organization, so if given the opportunity, I recommend supporting them as you see fit. Thanks to everyone that helped, and I hope that in some small way, both my efforts that night and my interpretations of them after the fact, helps you.

Agile Meetups and the Local Community

Zan Ongoing Agile Education

One of the greatest things about Scrum and Agile is the community of which we are all a part of.  Generally speaking, Agile Professionals, Scrum Masters and Agile Coaches are some of the nicest, most helpful people you can meet, and it shows in the community.  There are many blogs, online communities, and local meetups, all provided free of charge, where aspiring Agilists can go to gain knowledge and learn about different view points and techniques from some of the greatest and most prolific practitioners in the industry.  Local meetups embody this ideal, where a novice can attend a lean coffee, ask a question and get answers from peers, and often from very experienced Scrum Masters or Coaches who attend due to the love of Agile.

I’ve been attending Agile Meetups for years now here in the Los Angeles area, mostly with a group called Agile/Scrum LA.  They usually meet once a month, sometimes as an organized presentation event, but more often as an informal gathering known as Lean Coffee.  In Lean Coffee, the attendees each select a topic or question they’d like to speak on, write it on a card, and give a brief overview to the group.  The group then votes on which issues they are most interested to talk about, and the ideas are stack ranked for discussion. Then, a time boxed discussion is held about the topic, where the group can discuss more in depth. At the end of the time box, the team gives a thumbs up/down vote on whether to continue the discussion, or to move on to the next topic.  It’s a great event, using a microcosm of what makes Agile and Scrum work to talk about other things Agile.

I also recently started attending events down in Orange County, including my first Agile Drinkup.  This was an even more informal event, where a group of folks interested in Agile got together, had a few beverages, and just talk about some of our concerns, commonalities and community. It was great fun for me just to get out and pick the brains of people who have great experience being in this space, and the networking I was able to do may possibility help me find my next role as my search continues.

All in all, I heartily encourage anyone who reads this to take some time and join an Agile meetup. It’s one night a month, and the experience gained is far greater than the time cost. Also, the hours are applicable for the Scrum Alliance continued learning for certifications, so that’s a good bonus as well. I will post links to a few of the meetup groups I’m a part of below. Thanks for reading, and if you know of any other meetup groups in this space, please leave a comment below!

Agile/Scrum LA – Co-Hosted by Tyler Feiga & Jhade Barnes – A great group local to the West LA/South Bay area of Los Angeles. Lean coffee and some presentations.

Agile Coffee – a SoCal Lean Coffee Group – Co-Hosted by Vic Bonacci and Brett Palmer – Local to Orange County, I’ve had some great discussions here.

Agile Drink Up – Hosted by Dan Brown – I’ve only been once so far, as a co-hosted event with Agile Coffee, but I definitely plan to continue attending. It was a great time, and great conversations.

Thanks to all of the Agile Meetup Organizers for all that you do!

User Stories

Zan Ongoing Agile Education ,

Wow, it’s been a long time since I’ve posted!  Let’s rectify that!

I recently had a friend, who is moving into a new role working with a Scrum team, ask me about writing user stories, and if there was any specific training around creating them. After we finished the discussion, I recalled that I had created a presentation regarding user stories a while back. I’d like to share the presentation, and make some comments.

Power Point – User Stories

The presentation is linked above.  During this talk, it was important to emphasize the idea of “Outcomes over Output”, as the recipients of the presentation had historically been very directive and focused on directing output from contributors.  Changing this is a two-way street, as self-organization requires not only commitment from the team to organize themselves, but also commitment from leadership to allow for that organization to happen.  User Stories are one tool in that process, moving away from directive “micro-management” and more towards inclusive co-leadership.

This is just one in a series of presentations I’ve given in a series I’ve called “Ongoing Agile Education”. It was provided to a group who understood the basics of Agile, allowing for greater focus and discussion on a single topic.  If there is interest, I do have other Power Point presentations from this series that I may be able to post.

As always, I appreciate your feedback!

Estimation: Story Points and Time to Complete Are Not The Same

Zan Estimation ,

Story points are a pretty ubiquitous part of Agile by now.  In Agile, we use the idea of story points to add a layer of abstraction to estimation, to allow us to estimate based on relative size, and to stop ourselves from ascribing a false level of precision to our estimates. One thing that is always described as an Agile Anti-Pattern is basing your estimates or story points on how long one believes something will take to complete. Let’s take a bit more of an in depth look at why that is.

The premise

Throughout this example, I’ll be representing work being done in the form of eating apples, and other foods may make a guest appearance.  Apples are generally of a similar size and makeup to one another, and assuming there are no worms, they are also of similar complexity and risk, so we’ll use those to represent items of work that are also of similar sizes and makeups.

Everyone doesn’t work at the same rate

Let’s start with two apples. We’ll give two different people one each of those apples. Without any other context, you may believe that these two people will take about the same amount of time to finish eating those apples, and that may, in fact, be true. But what if one of those folks is a child? Or a world class speed-eating champion? The time they will be working on eating the apple may vary, but the outcome is the same: one eaten apple.

It’s the same when looking at work. Two people may take a different amount of time, even working on the same item, due to a number of different factors. That doesn’t change the size of the item being worked on, or the value you’ll derive from it’s completion.

Outside factors can change the time to complete

Other factors can also effect how long it takes to do something, without changing the size of what you’re doing. Let’s take one person eating one apple. Did said person just eat a huge lunch? Maybe they’re having dental issues? Any number of factors can change how long it will take to eat the apple, without changing the size of the apple.

The same can be said about a story.  There may be outside dependencies or blockers slowing down progress on an item, but that doesn’t change the size of the story itself, just the speed at which it can be done. Padding estimates due to known external factors comes with it’s own set of concerns, but suffice it to say that it doesn’t do any one any favors. (Note: This is assuming similar levels of uncertainly and complexity. Stories lacking clarity or those which are highly complex should be estimated higher… it’s a good lead in to another post for another time)

Improvements are not properly reflected, or hard to see

This time, lets take one apple, to be shared by a family. This family can take bites of the apple, and pass it around until it’s finished. By doing this, the family can eat one apple in 20 minutes, so lets say it earns them one “food point” in 20 minutes.  The family talks about it, and they determine they can share the apple better by slicing it, and eating pieces at the same time. This lets the family eat two apples in the same 20 minute time period.  Now, if they base the “food point” on the time it takes to eat the apple, and they said 20 minutes is the basis for a food point:

pointper20mincorrect

 

This means by improving their apple-eating methods, they actually decreased how many points an apple is “worth” in their scale. Note the apples haven’t changed in size, complexity or value.By doing this, the family’s velocity is 1 point, as they are still doing 20 minutes of work, however they completed twice as much.

Now, let’s base the points on the work item itself, by saying 1 apple = 1 point. Originally, they had completed 1 point per 20 minutes, and now they can complete 2 in the same time frame.  Therefore, their velocity increased from 1 to 2. (Also, look how much more simple that math was! Work smarter not harder…)

At the end of the day, both of these mean the same thing: twice as much work is being done in the same time period. However, by basing our abstraction on the work as opposed to the time the work “should” take, it is far easier to track how much our actions effect our output.

In conclusion

With estimation, we take a guess as to how big things are, to help us plan and scope.  We understand it is a guess, so we abstract this guess, so that we focus more on being roughly right as opposed to precisely wrong. When we abstract, it’s important to base our abstractions on values that can the most consistent and easiest to compare to a baseline, and in most cases, its generally work being done.

Questions about this, or comments? I’m always up for a good discussion. Please drop me a line in the comments below!

Scrum Teams vs.Online Team Gaming Mechanics

Zan Analogies, Scrum Masters, Team Dynamics , , ,

In a great blog post from Coding Epiphany from 2015, cross functional Scrum Teams were compared to RPG parties, mainly focused team makeup, skill specialization versus crossing roles and forming a team as you go.  It’s awesome and nerdy.  I had a similar idea, but instead of that comparison, I wanted to compare a Scrum Team to Team Mechanics from online gaming, mainly MMORPG or maybe some team based shooters. Continue reading →

The Case for Dedicated Scrum Masters

Zan Scrum Masters, Team Dynamics, Uncategorized , ,

“All our Scrum Master, Bob, does is sit around all sprint. I mean, he’s there for our Daily Scrums, and Sprint Planning. He goes to our Sprint Review and watches the stakeholders, and he asks a lot of questions in our Retrospectives, but what does he do the rest of the time? It’s not like he’s writing code…”

Have you heard something similar to that before? Maybe even said it yourself?  It’s a pretty common refrain, and one of the driving forces behind the idea that we can have part time Scrum Masters, and still be as effective as we think we should be.  Continue reading →

Zan’s Sprint Challenge 10/20/15: Practice Simplification to Improve Agility

Zan Uncategorized

It’s time for another Zan’s Challenge! These challenges are still to help spur your thoughts, strengthen your skills, or open your mind to new possibilities in Agile.

Today’s Challenge: Practice Simplification to Improve Agility

One of the core principles behind the Agile Manifesto is Simplicity:

Simplicity – the art of maximizing the amount of work not done – is essential.

In order to succeed, we all must learn to simplify what we are doing. It is never enough to just attack all the tasks and problems we may be faced with each day. There just are not enough hours in the day. We have to simplify the work we do, ensuring we get what needs to be done, done.

Here are some tips for simplification:

  • Make a priority list: It’s important to know what is the most important thing to be done is. Figure out what must be done first.
  • Understand the goal: If you don’t know what the goal is, and why the goal is important, you won’t know what to simplify.
  • Check your status often: Once you start doing things in their order of priority, check in as you complete tasks and see if you have met the goal. Sometimes, you’ll find the goal actually met, and you won’t need some of the tasks you thought you did at first! Other times, you may need to alter your expected tasks once you have new information. Either way, eliminating unnecessary tasks leads to simplification.

Good luck with this challenge. Please let me know your results, what you think of this challenge, and if you have any ideas for future Zan’s Challenges!

Zan’s Challenge 10/6/15: Identify Your Strengths and Weaknesses

Zan Challenge

It’s time for another Zan’s Challenge! These challenges are still to help spur your thoughts, strengthen your skills, or open your mind to new possibilities in Agile.

Today’s Challenge: Identify your strengths and weaknesses

It’s important, when striving for personal and professional growth, to know your strengths and at least some weaknesses which you can work to address.  We’d all like to think we have no weaknesses, but that is never the case. We all have something we can work to be better at.

Here are some tips to identifying strengths and weaknesses:

  • A quick way to know how strong you are at something is to try to teach it to someone else. Your understanding will be tested in new and unique ways, and teachers often find they learn just as much as their students.
  • Another really simple way is to just do it, whatever ‘it’ may be. While you’re doing something, examine how you feel. If you’re happy with the activity, you’re more likely to be strong. If it is frustrating or disconcerting, that is a sign you may be weak in that area. This applies to lots of different activities.
  • Ask trusted colleagues for their honest opinions. Give your honest opinion in return. Sometimes people know you better than you know yourself, especially when it comes to weaknesses.

Good luck with this challenge. Please let me know your results, what you think of this challenge, and if you have any ideas for future Zan’s Challenges!