Funny retro swimmer by the lake, at the sunset with copy space

If You Wait to Start Your Agile Initiative, You May Never Actually Start.

If you’re waiting for the perfect time to start an agile initiative or to launch a pilot program, you may be waiting quite for a while. You won’t always have the time/space/support or even all the “right people” for big kickoffs or to “officially start” for your program. When waiting on the “boat dock of perfect,” oftentimes opportunity sails right by, piña coladas in the blender.

Such was the case with a team I’m working with at a large government organization. They are one of the first agile pilots in the organization, and interestingly enough, they’re not IT. The start date kept getting pushed back because someone was on vacation. Then a new job posting was waiting to be filled. Then we were onboarding a new contractor. Then it bled into the 4th of July holiday. Then. Then. Then. You get the picture. We came to realize there would never be a perfect time to have an official kick off, training, or baseline assessment. This group of five incredibly capable individuals was eager to start and didn’t want to wait. So, we started.

Make Sense of the Chaos

In realizing there may never be a perfect time to start your agile initiative (hell, you may not even give a damn about an agile initiative, but know in your gut that your team can perform better), accept the fact that starting could be a little messy. There may not be an opportunity for the team to take a Fundamentals of Agile class or make a formal transition plan. You’re just going to jump in and start untangling the hairball of workstreams, roles, and Work in Progress (WIP).

One of the best ways–not the only way– to untangle the hairball is to start visualizing the work. A physical visualization creates the ability for a team to become aware of their norms, processes, and communication patterns. It’s also a powerful step toward self awareness, team awareness, and team empowerment. Often times, just understanding the team’s workflow, group dynamics, communication channels, and current team “norms” helps to level set “current state.” It creates a single lens that everyone can look through and forms a common ground. In other words, a baseline for perspective.

In short, visualization creates data points, data points create awareness, and awareness creates the ability to make educated, data-driven decisions from a similar perspective.

1. Document the Doing

Throw a Scrum or Kanban board on the wall.Have each team member write on a Post-it each individual task they’re doing and put it in the DOING column. (Don’t worry about the TO DO or DONE columns at this point.) Pretty soon, each team member will have a pretty good picture of all the things they’re juggling, as well as a good idea of what everyone else is doing, too.

For the team that I am currently working with, there wasn’t a huge “documentation of DOING event.” We just started by having daily stand- ups. Each day, as people talked about what they were doing, we would put Post-Its on the board, and pretty soon we were able to visualize all the work the team was doing.

This visualization exercise was especially beneficial because we knew the team was doing work, but we didn’t necessarily know WHO did WHAT work. As the Post-Its piled up, the WHAT and the WHO became clear. (Naturally, new stuff started popping up, so we started filling in the TO DO column.)

2. Understand the Process

Seeing this big picture–actually seeing it physically in front of you– will give you some very, very powerful information. Early on, through visualizing the work, our team was able to understand the workflow. We were able to understand the different workstreams (where the work was coming from), how work was distributed (by a single person hub spoke model), and how people got pigeonholed into work types (skill-centric roles).

It immediately became apparent that Work in Progress (WIP) was off the charts, and context switching (switching from one type of work to another) was out of control. One team member was switching across 8 workstreams on a daily basis! (How can someone focus with constant change?!) Having a better idea of workflow also allowed us to see who was making decisions and have informed conversations about work prioritization.

3. Make the Change

You’ve talked about it. You’ve visualized it. Now, armed with your newfound knowledge, start making hard decisions and incremental changes.

Incremental Change #1

As a team, we knew we wanted to eliminate the hub and spoke model of work distribution. Our goal was two fold: to create an environment where people committed to work they are interested in and capable of, and to take the administrative duties of assigning work away for anyone individual. We adopted Kanban, a pull system for workflow optimization.

Incremental Change #2

In implementing the pull system, we quickly learned that when someone became available, due to their respective specialized skill set, they were not always equipped to take the next highest-priority piece of work. We knew we couldn’t completely eliminate this from happening, but we knew we could make it a whole lot better than it was. This lead to the cross-training, “paired programming” initiative. As a non-IT department, we weren’t programming, but the idea remains the same: work in pairs to not only get the job done, but to create a cross-training learning experience.

Incremental Change #3

Similarly, we strove to greatly reduce WIP and find the sweet spot of what we could handle as a team. We found it helpful to document WIP at every stand-up. Dropping what we had already started wasn’t an option. So, our goal was to continue to shrink the amount of work in the DOING column. Simultaneously, we were creating disciplined behaviors. If something wasn’t ready to be worked on, we were to leave in the TO DO column until the last (ir)responsible moment.

Incremental Change #4

To help with understanding the workstreams (some being more important or time sensitive than others), we chose a color for each one and created a legend in the top right corner of our board . For example, blue for Quarterly Report, yellow for Data Science work. Each of our workflows and all its associated tasks would match the color of workstream they were related to. This not only served as a reminder for the team, but also provided at-a-glance information for anyone walking by outside of the delivery team.

On the same note, another trick we adopted was showing our workstream legend with the highest priority workstream on top. This would help keep us honest on our day to day decisions. When the team was prioritizing their work we could constantly compare our decisions to the workstream prioritization and make sure we were spending our time on the right things.

Don’t wait. Just start!

If you’re waiting for the perfect moment to launch your agile initiative, don’t. Just jump in. Your team should find it immensely helpful to visualize the work and harness the power of awareness. The picture that emerges will spark conversation, and more importantly, data-based decisions for change. Your team will feel informed and empowered to create a better way of working together. Plus, they’ll create a better delivery model for your customers. (And it’s all about the customer!)

If our team had waited for the perfect time to start, we’d still be waiting. Since we did the very first stand-up, a person changed positions within the team; we added a contractor to the team; and we’re in the process of onboarding one more person. Though not the ideal situation, we’ve improved by leaps and bounds. Now, when we onboard new people there will be a new baseline instead of the old way of doing things. Onward bound!

By: Darren Hoevel

“Each framework or methodology or certification is not the holy grail for how something should be done. Now I’m a believer in “do what works for you, what produces value.” The art is not in how perfectly you can follow a framework. What matters is that you’re progressing and learning and experimenting every single day. What matters is that you learn the approaches and practices and use them to your advantage. ” –Darren Hoevel (Me), the blog post Certifiably Certified

This is true, except when it’s not.

(I know, a typical coaching answer.) Sometimes the art IS in how perfectly you can follow a framework. Following the “rules” is especially important when your scrum team is “doing” agile and still can’t seem to deliver, or when they’re not improving, or when they’re delivering the wrong product. If this is the case, there is a good chance your team’s practices go against the values and principles (the framework, the rules) of agile.

When Redefining the Rules Doesn’t Work

More often than not (upwards of 70% of the time), when I enter an engagement and observe a team’s processes and practices, I see that they aren’t doing Scrum or Kanban by the book. They’ve abandoned certain practices or ceremonies and have adopted, they say, their own “method” of Scrum or Kanban.

Most commonly, this customization (or bastardization) involves dropping things of value (including but not limited to):

Daily Standups – This seems to be one of the first things to go. Teams will eliminate daily standups in favor of biweekly, or weekly status meetings.
Retrospectives – Teams decide to do retrospectives only if time permits, or drop them all together.
Limited Feedback Cycles (my favorite)- The team will “ghost” their customer for 6 – 12 months while they’re in “development,” eliminating any chance for customer interaction or feedback.
Only Testing in the Development Environment – Sometimes, the team won’t have the appropriate, well-configured environments to safely test their code. This can be due to cost constraints, or more often, it because IT does not have a good handle on their own environments including configuration management.
Not Pushing to Production – Your code will sit unusable if the cost of pushing to production (transaction cost) is greater than the value your code will create. So telling your customers that you “got to done” is not accurate, because it’s sitting in a non-production environment. You did not create or deliver value until it’s in production and usable by your customer!
Multiple POs for the Same Product – It’s a bad idea to have a PO for each segment of the business when you’re building one product. If everyone owns it, then no one owns it. Having multiple people, divisions, and/or opinions driving your product strategy will not only be the death of your product, but probably any relationship you have with your customer, as you will deliver something no one likes!

These teams say they’ve learned how to work together and don’t don’t need the ceremonies anymore, but about 99% of the time they’ve dropped these practices because it gives them extra time in their day to get more things done (which points to another problem like over utilization, WIP, or predefined delivery dates), or because they are too hard, or in order to inhibit “full utilization.” Not surprisingly, they’re now struggling to deliver, building the wrong product, and not working well as a team. By the way, this is even done by high-performing teams who are in the “flow” and decide they’re so good they don’t need these “extra” practices anymore, when those practices are precisely what made them so effective in the first place. Even on high-performing teams, continuous improvement is not always organic; teams have to make time for it.

Listen up, and repeat after me: It is not wise to drop a practice if it is not in support of a value and principle of the agile manifesto.

So let’s take a look and see how the bastardization of practices goes against the 12 principles:

Abandoning daily Standups and Retrospectives offends #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Limited Feedback Cycles disregards #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage; and #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Testing in a Development Environment defies #9: Continuous attention to technical excellence and good design enhances agility.
Not Pushing to Production goes against #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done; #7: Working software is the primary measure of progress; and, #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Multiple POs for the Same Product is in violation of #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software; #4: Business people and developers must work together daily throughout the project; and #11: The best architectures, requirements, and designs emerge from self-organizing teams.

If Your Team is Not Delivering or When You’re Delivering the Wrong Product, Go Back to Start

It’s a simple as this: All team members need to speak the same language. All team members need to know the ins and outs of the same processes. Maybe every team member has done Scrum or Kanban in the past, but each one of them may have been done a different “flavor” of Scrum or Kanban, or likely, they may not have been doing it right at all. So, do it by the book. Plan every sprint. Hold standups every day. Do every retrospective. Get on the same team. Follow the same rules. Get in the zone. Gel as a team.

Aside from developing team flow, and delivering the right product with low defects, and all that fun stuff, these practices good for team culture. Ceremonies offer direct communication and transparency, and if the teams are committed to continuous improvement, create a safe, respectful space for experimentation.

When you CAN Break the Framework Rules

It’s a simple as this: All team members need to speak the same language. All team members need to learn, adopt, and be in the same flow. Maybe every team member has done Scrum or Kanban in the past, but each one of them may have done a different “flavor” of Scrum or Kanban, or possibility, they may not have been doing it right at all (bastardization is everywhere). So, do it by the book. Plan every sprint. Hold standups every day. Do every retrospective. Get on the same page. Follow the same rules. Create your team norms. Get into flow. Learn it, be it, and live it as a team.

Aside from developing team flow, and delivering the right, high-quality products, and all that fun stuff, these practices are good for team culture. Ceremonies offer clear expectations, channels for direct communication, and transparency. And if the teams are committed to continuous improvement, they create a safe, respectful space for experimentation, success, and failure.

When CAN Your Break the Rules?

You’ve heard it before, but I’ll say it again: You can drop a practice if you’re still inline with the values and principles of the agile manifesto. Wait. We can’t drop the daily standups? Probably not, or at least it would not be my first consideration. Once you’re running like a well-oiled machine (could take a couple of weeks, could take many months), you could explore dropping something less “vital” (including but not limited to):

Estimating. You’ll know each team members’ skills and capacity, the complexity of the product, how much you can accomplish in an iteration as a team, the needs of your customer, etc. In other words, you’ll know the flow and capacity of your team. You may value estimates less and realize the conversation and flow are more important and the teams delivers on a predictable basis.
Remove the limited invite list to your Retrospectives. As your team starts to excel, delivering value every couple of days, constantly engaging with their customers, and sharing their successes with the rest of the organization, their hunger for improvement will grow. Pulling in other IT and customer groups will expand their Kaizen mindset, as well as the organizational reach for improvement.
Eliminate physical team boards and move to virtual boards. I’m stepping in to controversial waters here, but go with me. If your team is well synced and emphasizes transparency and communication, there may not be a need for a physical teamboard. It may well be enough to have a virtual board that is shared amongst the team and their customers. (I’ll just stress my opinion on this one: physical boards are an amazing tool and any team I’m working with would have to really justify this one to me.)

Constantly Reevaluate

In the spirit of inspect and adapt, constantly reevaluate your practices. Any time things start getting loosy-goosy and you’re team is not delivering like you used to, things are stagnant, you’re delivering the wrong product, or the team is just “off,” go back to the beginning. What worked before may not work now. Analyze where things start to get wobbly.

In the Face of Change, Start at the Beginning

It’s a good idea to take it back to “start” when you change or onboard a new team member. Everyone needs to speak the same team same language and be indoctrinated into the “norms” of the team and the organization. Take the time to get everyone educated and solidly on the same page.

It’s also important to follow the rules when you are adopting something that is very new and there is minimal institutional (in-house) knowledge. Your team will be unlearning their current “standard operating procedures” and building a new set of practices and knowledge within the organization. Similarly, the new practices are not only a different way of doing the work, but a huge cultural change for the organization. You will be unlearning established ideas and behaviors, unlearning a mindset of “that’s the way we have always done it,” building new “muscle memory,” new capabilities, and new cultural norms for the individual and the organization. So, start at the beginning and play by the rules.

There you have it folks. Make sure to stay true to agile values and principles! In case you want to become a better leader or team member, join me at my next Dare to Lead course.

By: Darren Hoevel

Don’t wait for the perfect time. Start by visualizing the work.

If You Wait to Start Your Agile Initiative, You May Never Actually Start.