I'm sitting in a conference room in Santa Clara with my Parent Company, Rovi, and a number of other participants, and we are having a private session of AgilePalooza. This was prompted by the fact that Rovi, as a whole, has decided to embrace Agile. Sidereel has been "Agile" since day one and before we were acquired, but Rovi has a number of different product lines, many of which are from acquired companies. Because of this, they are making a much greater leap than the one Sidereel made. As such, I thought it would be interesting to see how this whole "Agile" thing is being taught for those who don't already play with it. Seeing as I was thrown in the deep end last year and had to make it up as I went along, I also wanted to see how this is "supposed to work". My thanks to the Sidereel team for giving me a day to explore this.
Our first part of the day started with Steve Davis of Davisbase Consulting, and he is describing the philosophy behind Agile, but more to the point, the stumbling blocks that get in the way of companies successfully implementing Agile. Steve made a case that, while may organizations provide feedback as to what works and what doesn't, there's a huge part of the feedback loop missing… the companies that tried Agile and bailed on it. The importance with Agile and getting a team to be effective isn't really about process, it's about where they ultimately want to be. "Begin with the end in mind" to borrow from Steven Covey's second Effectiveness Principle.
A challenge with adopting Agile is that a team, a company, and a culture needs to believe that it's going to actually work. To that end, getting involved early and learning early is critical. Believing that you can be Agile is good, but it's not enough, and more to the point, it's not a one time event. Teams need to work continuously to get better and actually understand what they are doing, what they appreciate, what they hate, and what areas can be improved upon. There will be challenges, and there will be cultural issues that will either get masked by the process, or it will be ripped bare and made public by the process. How we handle them is important, and often it's very incrementally and iteratively.
I'm impressed with how the concepts of "Shuhari" (Obey, Digress, Transcend) and "Kaizen" (Continuously Improve) come into play here. Shuhari is a concept within martial arts where learning and development along with mastery often supersede the elemental forms that we fist slavishly follow. Mastery is more than rote following. Sometimes it requires transcending and changing the old forms. Kaizen is the idea of continuous improvement, the actual doing of the concepts that make up Shuhari (or Agile, in this context). Mastery, though, comes down to doing, and doing a lot. Just slapping a label like Agile onto a company will not make it Agile. Habits may also involve people differently. In my own work, I have opportunities to "play by the rules" of Agile, but sometimes I have to make up my own rules just because of the nature of what I do. Just because there is a system, doesn't mean that being a slave to that system will be effective. Perhaps this is a difference between lover case "agile" and uppercase "Agile". It's not a one size fits all situation; some things may have to be adapted. Regardless, we can't just pay lip service to it, we have to actually do it. The Shuhari style terms for Agile are "Knowing, Doing, Becoming".
The next step goes beyond the process, and involves the people. Ultimately, it's the people that make an Agile transition effective. It's common to have people who make the move to Agile still keep their same infrastructure as before. In many ways, this alignment entrenches old behaviors and habits, because very often we are beholden to the people that we interact with, rather than our involvement with an arbitrary ideal team concept. If you must "measure" to help make your teams effective, try to utilize positive measurements. Are you a good team? Do you have good team members? Are you individually good at what you are supposed to be good at? Your customers will determine the first one. Your team members may help determine how you are doing with the second one. Ultimately, number three is entirely up to the individual.
We are social beings. Social community is more than a buzzword for networks like Facebook, Quora or Pinterest. It's a real currency and the way that we are genuinely motivated. When we learn socially, we learn dependably and often better than any other manner. Our social connections in our organizations will often drive the way that we learn and how we apply what we do. We also do things less for the work, less for the sake of it, and much more for the love (or at least care and appreciation) of our immediate team. Ultimately, though, if you must measure, measure based on the customer and how happy they are with what has been delivered and continues to be delivered.
After the primary presentation. we had a round table discussion specific to questions asked by the attendees, and some discussions about challenges faced by those looking to implement Agile. One of the most common is impatience. Interestingly, it's not executive impatience that causes problems, it's the practitioners' impatience. This is where having a clear and strong vision, and a realistic time frame is critical. Additional to the impatience is to try to figure out how to determine if we are actually making real progress. The answer is based on the features and whether or not they are actually being used by their customers. By comparison, when customer satisfaction is actually measured, a lot of pet projects go by the wayside. Though a long term goal is to get beyond looking at the end of the quarter or the current stock price, the truth is, those are relevant measures, and if both are declining, it's hard to keep a transitional initiative alive and thriving. Agile transitions don't happen overnight, especially for organizations that have set formats and established cultures. It takes years to develop that, and often, it will take years to develop out of it. If you have to measure for metrics, measure for the change you are hoping to achieve. Also, metrics are not set in stone, nor should they be. Once you have established a pattern, get rid of the metric.
As we were discussing dependencies, I couldn't help but chuckle when the facilitator asked what some "best practices" were to help resolve issues with those dependencies (I refrained from saying "there are no such thing as best practices, just good practices in context!", but I figured I was in a different crowd, so I didn't say it there... I'm saying it here though ;) ). This is a real problem for an organization that has products that depend on each other to make a cohesive strategy. Sidereel is in many ways a standalone product, but as far as Rovi is concerned, its an integral part of its digital media offerings. Things we do have an effect on other product lines now, and thus, Sidereel is a dependency for other initiatives. It's interesting to be reminded of that fact. Dependencies crop up all the time, so it's better to be aware of them and how to work with them, rather than having them become a stumbling block. Keeping on top of issues and dependencies can help make sure that the challenges associated with them are minimized.
We had a discussion of splitting focuses and projects, and I like the idea of "one backlog, one team". Instead of having side projects and products, the team has one back log, and that backlog is visible to all. This way, it becomes possible to see all of the work that the team is facing, and how to decide what they will prioritize and what will get worked on, and what won't be. Transparency is critical; having too many hidden items can crush a teams momentum. It also helps set up the real expectations for the team, so that everyone can address the work load in a practical way (dealing with Expectational Debt; I like it :) ).
A great deal of the later discussions have been specific to the tool implementation and how to utilize the tool (VersionOne is a tool vendor, and they are sponsoring today's event). While a lot of the discussion is being spent on how to implement Agile using VersionOne, there's still some good ideas being discussed and some perspectives I have not considered. Issues such as using Scrum in with distributed teams, how to carve up one large team into multiple smaller teams, making sure that a key technology is not being modified by two separate teams simultaneously (talk to each other!), and how to get multiple scrum teams to communicate. One interesting question that branched into a good discussion was how we could get more action out of a retrospective. That's a topic that could take an entire day, but it gave me a chance to share a good practice we use called a mini-retro. rather than wait two weeks or an entire month before a retrospective, we have a mini-retro every week, with simple parameters and the goal of getting a small number of action items to focus on for that coming week, rather than have a large list of action items that might prove to be overwhelming if taken on at a regular retro.
Following lunch, I had a chance to talk to the vendors and consulting team for VersionOne, and discovered that we knew a lot of the same people (my ears perked up when one of the consultants made a comment and quoted Dale Emory :). When he saw me perk up, e decided he had to find out how I knew about Dale, and a lot of great talking (and some laughs) ensued.
It's been fun, thanks for playing along.
No comments:
Post a Comment