Why do we stand up at the daily stand up?

A few weeks back, I saw this picture in a Scrum Master Community on Facebook and while I added comments to the thread, my brain started spinning and I asked myself “Why do I feel it’s important to stand up at the daily stand up?”. The answer that is typically written in Scrum posts and forums is that it keeps the meeting short because nobody wants to physically stand there for longer than 15 minutes while people talk and drag on, and if you sit down you are more comfortable and it provides a greater chance the meeting will carry on. While I can buy that, I don’t truly believe that’s the important reason behind why we stand up and other method’s can keep a meeting short and on track as well.

Note: I want to go ahead and get this out of the way; my thoughts on this are likely controversial and even perhaps a bit far fetched, but hear me out for a minute.

When I went through Air Force boot camp, we woke up every morning at 4:30 am and the very first thing we did was make our beds. However, it wasn’t as simple as just pulling the covers up and making sure the bed looked somewhat presentable.  You had to practically strip the bed and start from scratch to ensure you had proper hospital corners and there better not be a wrinkle to be found. There was a fold over your pillow that had to be so tight that the drill sergeant could pull it up slightly with his finger and once he removed his finger, it would snap back down like a rubber band. Did making our beds in this manner really better prepare us to fight a war? Absolutely not! However, I once heard a very wise 4 star general speak on this manner and he stated very well that:

• By doing this, you start your day off by accomplishing something very first thing. This kick starts your day and makes it productive.
• It instills the behavior of paying attention to details. If you can’t make your bed properly, how can they trust you to operate machinery or to make battle plans that involve the lives of other individuals. Not paying attention to details can mean getting your friend blown up by a road side bomb. It’s all about the details. 

Every member of the armed forces goes through this during basic training, and most, if not all, find this a pointless task at the time. However, it’s one of the “trials” you go through that ultimately builds a bond and takes a unit from being a group of individuals and turns them into a team that works and fights together.

Now before you think I’m trying to compare Scrum to war, let me give you one other brief analogy. I graduated from Alabama and I’m a huge Alabama football fan. The team has won 4 National Championships in the last 7 years which is an incredible feat. One thing you often hear Nick Saban talk about is “The Process”. Every detail is planned out by his coaching staff and they push the team harder than any other program in America. Ask any of the 18-22 year olds on the team whether they like everything they go through in the hot 90-degree summer heat and they’ll tell you probably not. According to Nick Saban, the difference between the teams that won, aka hit their sprint goal(s), and those that didn’t, is all about whether they cut corners or acted as individuals instead of a team.

So why do I believe it’s important to stand up at the daily stand up? It’s one way of saying to your team, “This team is important to me and I’m committed to it’s success.” It’s one way of showing you respect the team and will do your part to ensure we hit the sprint goal. It may seem like such a small thing whether you are standing up or sitting down when you gather around your [Story Wall, Task Wall, whatever you use for stand up], but it’s little details like this that bond a team together and can be the difference between good teams and great teams.

In the book “Scrum:The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland, he talks about how Scrum teams can produce incredible productivity gains (he mentions teams that have increased productivity by 1200%) by adopting Scrum. Reading between the lines though, I don’t think these teams experienced those types of gains just by adopting Scrum practices; I think they were truly bought in as a team and operated as a team in conjunction with Scrum practices. I imagine those teams were truly committed to a productive daily stand up, were truly committed to each other during meetings instead of staring at laptops, were truly committed to working together on a daily basis in order to achieve far more than the collective group could do individually.

With all of that being said, will I force my teams to stand up at the daily stand up? Absolutely not! I’m a servant leader and here for them, not the other way around. Will I continue to encourage them into these types of behaviors? Every single day. It’s the small things, like standing up at stand up, that I believe truly brings a team together and separates good teams from great teams. It’s in the details of the hundred’s and thousands of interactions the team has that propels them to great things.

What do you think? Am I completely off base? Please leave comments and let me know your views on this.

Post-Its vs Agile Project Management Software

While some of the posts I’ve written recently, I’ve had a specific point I wanted to make, today’s topic is really about a current experiment I’m running and whether organizing our work digitally or with physical hands on artifacts is better. This is not anything new that I invented, and I’m sure countless thousands of Scrum Masters before me have done this with their team. This is just a placeholder for me to be able to look back in time and see things I tried or what my general way of thinking was and how that’s evolved; and hopefully I’ll generate some comments from you so I can learn about things you are doing!

Problem:

The team started missing sprint goals and carrying over work sprint to sprint, and the daily stand up did not seem to provide the transparency or accountability that a team ideally needs to help collectively move the sprint forward each day.

Said another way, while we follow the “Yesterday I did, Today I plan to do… “ format, the updates were extremely vague and it was tough for me as the Scrum Master to really tell what progress, if any, we made the day prior. In addition, the team did not hold each other accountable and stories seemed to drag on longer than they should be.

Looking at this bigger problem above, there are any number of potential reasons that these issues could be coming up including:

• Are the stories groomed properly? Clear Acceptance Criteria and Definition of Done?
• Are we committing to too much work each sprint?
• Are we facing impediments and not surfacing them?
• Does the team not trust each other enough to hold each other accountable each day?

However, the purpose of this post is simply to discuss one experiment I’m trying to help with the daily stand up piece. The other questions will have to be left for another day J

At CareerBuilder, we use Mingle as our Project Management Software and for the most part all of our teams manage their work with a digital scrum board, including both of mine. However, when reading Jeff Patton’s User Story Mapping and listening to speakers or reading blogs, a lot of them still heavily reference using physical post-its and having that information up on a visible wall. So I talked with my Engineering Lead and shared that one of the concerns I had with our missed sprint goals was the lack of clear direction and accountability in our daily stand up, and that I’d like to bring a physical sprint board into our area and move towards using post-it notes during our stand ups (see picture). He was on board and we brought it to the team, and we are now heading into our second sprint using this.

Our Sprint Board in preparation for our next sprint

Prior to this, we had user stories, but did not really task those user stories out. Since a user story on average can be anywhere from 1-3 days (some more, some less), it become a little too easy to talk about the same story for a few days without providing any real clarity on what parts of it you got done. For the last two sprint planning sessions, we are now taking our user stories, and instead of just having a general discussion on what needs to be built (which tended to include some of the technical things that needed to be done anyway), we are actually trying to identify and create as many of the tasks as we know about for that user story. We aim to identify ~70-80% of the tasks and we know we’ll identify more as we learn during the sprint.

At the start of the sprint, all of the tasks we identified go up as individual post-its on our physical sprint board. The way I’m coaching the team is that while a story can take multiple days to complete, if a task takes longer than a day, it means one of three things:

1.     We sat on our hands and did nothing the day prior

2.     The task is too large and should have been broken down

3.     We are facing impediments to getting that task done

When we come to stand up each morning and can’t move a task forward though, it at least provides a very clear signal that one of those three things happened and we need to figure out which one it was and work to fix it.

It’s been a work in progress and the first sprint was a little bumpy on understanding that it’s ok to break tasks down into further chunks. The main point of introducing the tasks was to allow them to break the work down into hour long, or 2-4 hour, or whatever chunks of work allows them to best organize their day and hold themselves accountable to the progress they are making.

It was very cool to see one of the Engineers walk over late afternoon on the second to last day of the sprint, and move along two task cards that wrapped up her story! I think when we do everything digitally, it’s a little easier to hide things than when you have a physical board right out in front of the team. But on the flip side of hiding things, it’s also cool that it’s a visible sign and cause for celebration when someone can walk up and move sprint goals along!

Feedback thus far has been positive and the team has agreed to at least continue on for a few more sprints. In general, they seem to like the visible reminder right in our area, because while they can ignore Mingle, it’s tough to ignore a white board right in front of them. I’ll try to remember to write a follow up on this after I see if we start getting the desired results.

One quick note, we do still use Mingle for tracking our stories; we just added the physical white board for our daily stand up meetings to discuss the tasks associated with those stories. I’m not as worried about tracking data on the task cards though so we don’t require those to be in Mingle.

Do you and your teams prefer just working with the software versions or have you tried the old school touch and feel of post-its as well?

Be Agile, Don’t Do Agile

About 9 months ago, I transitioned out of IT Recruiting and into my current role as an Agile Project Manager. I was full of textbook knowledge and eager to start on my Agile journey, but mostly still uncertain of exactly what to expect or what the job entailed.

The past 9 months have flown by as I day by day begin to fully understand my job; mostly through trying things out, messing up, and hopefully learning from my mistakes. One thing I can tell you for certain is that at a minimum, the dev teams I support see that I try on a daily basis to help them out and to drive us towards continual improvement. I refuse to be the APM that merely facilitates meetings and enforces the “Agile process”; I want to be seen as a valuable member of the team, and what that requires to be seen as valuable means two different things to the two teams I support.

So back to the point of this topic. When I started out, I kind of assumed there was a “right way to do Agile” and the lens that I viewed my teams through was basically, is that the proper way to do things or are we doing it wrong? Nine months in and I can now tell you that it’s the wrong way to approach coaching an Agile team.

Through my self-studies (I’m prepping for the PMI-ACP and typically have 2-3 books I'm reading all at the same time) and even presentations from Agile Day Atlanta, I’m learning that it’s really more important to “Be Agile” rather than “Doing Agile”. What do I mean by that? I’m glad you asked. It's about developing an Agile Mindset rather than following a specific set of processes.

I started out wanting to make sure we were “Doing Agile” and following all of the ceremonies correctly and doing things a certain prescribed way. Certainly if we followed the recipe we would build better software right? Something funny happened though; it didn’t always work out that way and the team didn’t always respond to textbook Agile.

I attended Agile Day Atlanta this past Friday, and our keynote speaker was Doc Norton. He gave his talk on the “Experimentation Mindset” and the more I’ve learned about Agile, I’m starting to realize that it really comes down to two things: Experimentation & Learnings.

Why do we retro? To learn from our prior successes and failures. If your team hates to retro, it means one of two things. Either your ScrumMaster does a horrible job of facilitating meaningful discussions, or the team is approaching it with the wrong mindset and does not really come prepared to observe and learn.

Why do we work in iterations? To run quick experiments that we can put in front of users and learn from. Jeff Patton’s book on User Story Mapping had a great passage, which to summarize basically says, for every story you want in the backlog you should write three stories. The first has the story, the second says fix the first card, and the third says fix the second card. His point is that we should be going through iterative learning cycles and we will rarely build the feature “right” the first time. If you aren’t following this cycle, you likely aren’t learning from the software you build.

User Story Mapping is actually what kind of inspired this topic. As I’ve worked to coach my teams through writing better stories, we’ve struggled with trying to do it “the right way”. We’ve basically taken the old school documentation process from waterfall and just tried to repeat it with our Agile process. What I’ve learned from this is that I need to teach this in a way that isn’t so prescriptive, but rather focuses on the mindset of telling stories and gets the whole team to a shared understanding of WHAT we’re building. What gets written on the card is largely irrelevant after that as long as it helps trigger our memories to the meaningful conversations we are having around the card.

So what does Agile mean to me in my day to day for coaching Agile teams? It’s becoming more about fostering a safe environment where we are free to experiment and learn. I think if those two things happen, then we can say we are “Being Agile”

What do you think? Please leave any questions or comments you might have as this is a work in progress for me and I fully expect to get some things wrong and hopefully learn as I go along!