Is Agile the New "Normal"?

I was listening to the Agile for Humans podcast this week featuring Steve Denning, and he spoke about a topic that I’ve either heard or read about several times over the last several months. In all cases, it has been some form of “Is Agile Dead?” or “Is it time for the Agile Manifesto 2.0?”. It kind of triggered this idea in my head which is, has Agile become the new normal?

Humans go through change continually. What ultimately happens is that at first, the change makes you uncomfortable, but with time you adapt to that change and it slowly becomes comfortable, or the new normal (think weight lifting, a new diet, starting a running program, learning a new skill, etc.). Normal isn’t by itself a bad thing. However, throughout the history of mankind, we have a track record of revolutionary new changes that over time become distorted.

                        

In his book “1984”, George Orwell tells the story of a group of farm animals who are fed up with the farmers living off their hard work. At first, they overthrow the humans and begin to celebrate their new found freedom and all is great! Eventually, though, the pigs move into the house and slowly begin making small changes which the animals reluctantly accept. Before you know it the pigs have become indistinguishable from the humans they once fought against, and the rest of the farm animals fight to drive the pigs off. 

In colonial America, the colonists were fed up with the British and had a slogan of “No Taxation without Representation”. Eventually, in the American Revolution, they overthrew the British government and formed what we now know as the United States of America. Yet a little over 200 years later, most Americans do not feel the politicians in Washington have their best interest at heart and instead act in their own best interests. Those in Washington seem all for passing policies that help them stay career politicians that live lavish lifestyles compared to the average American. Both sides of the aisle advertise changing Washington for the average American, but rarely do we see that.

Now Agile is obviously not a political upheaval, but there are some parallel storylines. A group of individuals that were fed up with the waterfall way of doing things got together and said, “There must be a better way of doing things.” They wrote the Agile Manifesto and frameworks such as Scrum, XP, Kanban, etc. started to form. Software was developed more quickly, developers had more fun building the software, and everything seemed to be great in the world of Software Development. However, somewhere along the line, we once again started polluting Agile and in some cases, it became about checking things off a checklist to say we are Agile. It became “Doing Agile” instead of “Being Agile”.

I’m fortunate in that I have never worked in a formal Waterfall environment, and for the most part, the company I work for is pretty good at Agile (some teams better than others). However, I have still witnessed projects that although described and worked in the name of Agile, sure do resemble the waterfall projects of old. I will often hear comments from developers and business people alike made in the name of Agile, but that show they don’t seem to truly understand Agile. It’s as if they have taken the Agile buzz words and then started using them to describe old behaviors; as if calling the behavior by a new name will change it and make it more Agile and less Waterfall.

If you look up the definition of Agile, you’ll find something along the lines of “able to move quickly or easily.” The whole point of being able to move quickly or easily though is that it allows you to put software in front of a customer sooner, and LEARN from it. The key to doing Agile is that you should be continually trying something, inspecting it, and learning from it.

We hire knowledge workers [Software Engineers] that make salaries well above the national average, but in many cases, we don’t let them actually do what they are hired to do. We ask them to do more and more in terms of delivering new features, give them very little time to really think through a creative solution and learn from the software they are building, and we do this all in the name of Agile.

If you really want to be an Agile organization instead of just being an organization that does Agile, throw out all the checklists and buzz words and focus on becoming an organization that experiments and learns. Provide a real problem from your customers and allow your knowledge workers time to really think about the potential solutions and then iterate on those solutions. Try something, show it to your customer, learn from it, rinse and repeat.

So what do you think, has Agile become the new normal?

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.

User Story Mapping Workshop

I’m about a week or two behind on writing anything, but I’ve been out of town for the last two weekends for a bachelor party and wedding of a good friend of mine, and I just haven’t made time. Anyway, I wanted to write a follow up piece on my earlier post of How Not to Do User Story Mapping. I mentioned in that post that I was planning a workshop on User Story Mapping and Adaptive Planning, and I wanted to write a follow up on how my workshop went.

WARNING: This post turned out kind of long! Sorry I’m long winded…

This was the first workshop I’ve conducted since leaving recruiting and transitioning into an Agile Project Manager role, so I’m by no means an expert, but I’ll at least share my experience.

Before I get started, I want to summarize why I believe User Story Mapping is so beneficial, just in case you are unfamiliar with the concept or haven’t done them yourself. As I’ve mentioned in prior posts, I support two highly technical backend shared services teams, and the stories we were writing were very detailed and complex and it was nearly impossible to see how they tied into the big picture of what we were building. In fact, I found that we often were building something without truly understanding the big picture or how it tied into the problems we were trying to solve for our customers. Then the APM team decided to read User Story Mapping by Jeff Patton for our Q2 book read and it couldn’t have come at a better time!

The idea behind user story mapping is that you bring ALL project stakeholders together to talk about the Who, What, Why of a project and build out a map of what software needs to be built to solve a customer problem. It helps everyone to gain a shared understanding of what is being built, and with larger projects that are split among many different teams (which tends to happen at CareerBuilder), it gets us all on the same page with the complexity of the project and everyone better understands who is building what (i.e. better visibility into dependencies).

For my workshop, I used three resources to help me prepare:

1. User Story Mapping by Jeff Patton (I highly recommend this book)
2. Chapter 5 on Adaptive Planning from the PMI-ACP exam prep book
3. YouTube video by Ahmed Sidky on Agile Estimation (I also referenced his paper here).

I’m very fortunate in that I had full support from my Dev Manager, Product Owner, and Engineering Lead, as well as buy-in from the team to take a full afternoon to run this workshop. That’s four hours of sitting in a room and listening to me talk! Just kidding… we had plenty of activities mixed in, but I still appreciate them actively participating when I’m sure they would rather have been at their desk coding.

I structured the workshop to follow the sequence of events of planning out a new project: Build a User Story Map, High Level Affinity Estimation, break the map into potential releases, low level planning poker (using relative vs absolute sizing, and complexity [size] vs time), release and sprint planning, and finally daily stand up.

For the workshop, my Product Owner came up with a fictional app that would control a robot to do lots of activities around the home (think the Jetsons) such as cooking, cleaning, laundry, etc. Because we are a backend team, they didn’t want to do an e-commerce style site and wanted something that would involve a little more infrastructure setup. I also wanted it to be different enough from their day to day work so that they wouldn’t immediately try to translate everything back to their work, and instead would focus on learning what User Story Mapping is all about.

Unfortunately, I think I still struggled to help them understand the story flow that comes from building out the Backbone and Walking Skeleton. I ended up abandoning that and moving towards building a story map that would show how you get ready for work in the morning. Even though not all Story Maps have to flow left to right chronologically, you generally want to map out how a user would use your software in a left to right format, and getting ready in the morning helped to show that. The getting ready in the morning example also helped the discussion on breaking the map into releases as things like exercising in the morning may not be MVP. It helped to demonstrate how we might move stories up or down in the releases depending upon how important they are (note: that also depends on your customer though; exercising may be a mandatory story for MVP for some people, whereas for others it can go farther down. The key point being you need to understand your customer for planning out MVP and future releases).

For all of the estimation parts of the workshop, I pretty much copied everything Ahmed did in his YouTube video. This was probably the part of the workshop that resonated most with the team, so I’m glad I did. Practicing planning poker with the fictional “unpacking a Uhaul” example really helped us to surface a few things that we could learn about estimating together. For starters, during the workshop we made several assumptions and it was only after discussing why our estimates were so far apart that we realized we hadn’t asked the right question yet. It was cool to see the light bulb go off when the answer to that question helped us to then better estimate.

A lot of people complain about estimates and say that all of the time we spend estimating is wasteful, and that we could actually be building the software instead. I argue that they are missing the point of estimation; yes, the business needs estimates (which the developers personally could not care less about), but it is also a key tool to help the team ensure we truly have a shared understanding of what we are building. An initial estimate that varies is actually a great thing because it forces a conversation and develops shared understanding; if everyone throws out the same number that can actually be scary, because then you wonder if we all truly have the same understanding of the complexity in mind.

Overall the workshop went very well and the team learned a lot about User Story Mapping and Adaptive Planning. I gathered feedback from the workshop and the biggest takeaway was they would have liked an example that was closer to the work they do because we still had a big hang up on where Infrastructure fell into the User Story Mapping. I think they’ve been a little burned in the past because the business doesn’t understand the setup needed to actually start building end user functionality. I think that’s partially because we’ve never come together as a group (front end, back end, product, business, etc.) to discuss a project like this. I don’t want to say we haven’t had the buy-in of key stakeholders, because I don’t think we’ve asked stakeholders (or even other teams) to attend a session like this, but we definitely have not mapped out projects together like this in the past. If we bring all of the teams together and build a map together, we can still create a backbone and walking skeleton that is user functionality focused, and then use different color post-its to help everyone see the different layers of functionality that have to be built before that user benefit occurs. The business may not like all of the infrastructure that has to be set up initially, but at least they’ll have a better understanding of what we are doing and why we are doing it.

Only time will tell if we can get the buy-in across groups to do User Story Mapping sessions together. At a minimum, this team at least now understands how we can map out our next project so that we better understand the big picture, and how we can also provide better visibility into the full scope of the project. One thing I can already tell a noticeable difference in is our estimation sessions. I think this workshop helped them think differently, but it also helped me to better grasp some key concepts and metaphors to use to ensure we keep our estimates as relative complexity based versus absolute time based.

Do you do User Story Mapping sessions for projects? How did you get buy-in from all stakeholders?

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?