Posts tagged ‘Agility’

March 22nd, 2013

Finding Organizational Flow (Part 9 of the Agile Leadership Engagement Series)

Becoming an organization with agility at its core will require a natural pull and flow between leadership and product teams. Especially as companies grow larger, this conduit between the organizational vision created by senior leadership, strategic planning by mid-level leaders, and the product vision created by the product owner has a tendency to become smaller and smaller, slower and slower, or doesn’t exist at all any more to the point of varying degrees of organizational dysfunction.

With the last post of the series, I’ll share a few thoughts on how we can begin to build a free-flowing partnership between leadership layers and product teams.

The communication conduit often clogs at mid-level leaders. The strategic vision does not reach the teams and if it does, the vision has been filtered to a point where it no longer resonates or inspires. Insight into user needs and potential product features found during discovery from the product teams only reaches so far into the visioning exercise or doesn’t happen at all.

To function with business agility we will need to see an unwavering level of responsiveness to changing business and market conditions. It will also require a resilient level of trust and respect to attempt new things and build on ideas from every corner of the company.Finding Organizational Flow through Leadership Partnership

To ultimately make the level of nimbleness and adaptability necessary to be competitive I believe, as others do, organizations of the future will need to be less hierarchical than they are today. But until that day arrives, here are a few starting points to consider:

Focus outward. Redirecting our energy towards our customers will require a bit of selflessness. It will mean being generous with each other, primarily through learning how to really listen to one another. Instead of being the hoarder of information, our first response when new data, theories, and ideas arrive should be “who should know this?” Become a radiator of information to all.

Learn how to resolve conflict. As we all know, there will be different opinions and beliefs on what features will best meet our customers needs. All one needs to know about how innovative an organization is can be gauged by how they work through these conflicts. From the Denma Translation of the Art of War, “This is not simply about bringing the other person over to your side but bringing him or her to something larger than either side.” This is where real innovation and collaboration lives.

Temper the vision with reality. As Thomas Edison said, “Vision without execution is hallucination.” If the vision calls for revolutionary innovation, more investment may be required or serious prioritization must occur during planning. Bring organizational feasibility into the vision by co-creating with mid-level leaders and product owners.

 

June 27th, 2012

The Power of Pilots

Leaders are tempted to decide on organizational or workflow changes and reveal them with a “big bang.” The reveal will often include a new org chart with the instructions that we’ll figure out the details later. As organizations grow larger and more complex, the success of implementing change in this way becomes questionable. At the very least, the changes will be stressful but they are often painful to those affected.

As I see it, here are a few of the problems with using the big bang approach when it comes to organizational change.

First, the changes are often designed in isolation. Change originated in isolation is rarely received well – even if the change being designed is solid and sound.

Second, the changes are often reactionary. Change originated as a reaction to a negative event or issue will often bring emotion and politics into play.

Third, the changes are often made in desperation. Change originated from desperation will limit options and creativity.

An alternative approach would be to use pilots to prepare and engage an organization around the change. Pilots are small, controlled initiatives with a select group of people or teams. During our Agile transformation, we used pilots extensively to see what would work with our organization and what would not.

There are cases when a change cannot be piloted but if you start early most of them can. Here are a few of the advantages in piloting organizational change initiatives:

They put ownership in the hands of those most impacted. Change is not easy on people. Most people do not like change and they especially don’t like it when they feel like they have no control over what is changing.

They allow you to experiment with your ideas. Looking to merge departments or remove constraints in the value stream? Setup a small transformation team to capture the current pain points and use the pilots to experiment with new roles, activities, or work products.

They allow adjustments to be made. Once the pilots are underway, use them to learn how the changes are received and if they are effective. Make changes as necessary and pilot them again.

They build examples and evangelists of the change you are looking for. Once a pilot is deemed successful and the change is moved to a broader implementation the people on the pilots become advocates and evangelists for the change.

Again, starting change initiatives early and getting those who are impacted involved will allow organizational change to be truly transformative…and you may find that you have created an empowered workforce along the way.

June 12th, 2012

There’s a Glitch in the Matrix – Getting an Agile Team Back into Flow

One of the attributes of a healthy Agile organization are teams being in a state of flow. You can easily tell when a team is in flow. There is a sense of purpose and vision, there is very little stress, there is laughter and comraderie. They are committed to each other, and when a challenge comes, they handle it together, without drama. They just solve problems, together. The team is not perfect but they sense when something is not right and self-heal.

It seems like the team in flow gets more done than any other team and from outside appearances, they make it look effortless. Sound to good to be true? I’ve seen and experienced teams like this. They are a joy to watch and its absolutely possible.

Now, when a team is the opposite, they are out of flow, the results can be damaging and perhaps even create an unhealthy environment for team members. When teams become out of flow, they:

  • Are always playing catch up. It feels like they are on a treadmill with the incline slowly being increased to an unsustainable height.
  • Will have a tough time reacting to change as its challenging enough getting planned stories completed. The team heart rate is too high from the increasing incline to tackle the next hill.
  • Are challenged to establish retrospectives as a time of gratitude and renewal as these sessions will often devolve into gripe or blame sessions. They are out of breath to put meaningful effort into making this session a time of true retrospect, collaboration, and improvement. They may be too tired to even realize they are out of flow.

If you have a team out of flow, here are some steps to bring them back:

1. Go Back to Basics
Always start with this one. Pull out your Agile framework or Scrum Guide and facilitate a team basic training session. In many cases, a team becomes out of flow when there is a deviation from the framework. Someone is not fully living into their role, a work product is not being produced as it should be, or an activity is not happening when it should be. Bring the team back to “shu” in the “shu-ha-ri” levels of practice.

2. Look at the Planning Session
Once the team has a solid understanding of the basics, observe the sprint planning session. Is the team asking the hard questions during this session? Have they sufficiently answered issues around technical feasibility? Nothing stops a sprint faster than large, unresolved technical design questions. Are user stories well-written with robust acceptance criteria? Is the team over committing? “Flow” can be designed and planned and it starts with this session.

3. Promote the Vision
Give the team a reason to get back into flow. Is the product vision strong and compelling? If not, it may be time for the product owner to take another look at the vision and freshen it up. If the vision is solid, then promote and publicize it. When a vision is exciting and worth pursuing, the team will rally around it.

4. Protect the Team
Distractions from leaders, other teams, and requests from other areas may be pulling attention and time away from your sprint goals and causing team members frustration or anxiety. Do whatever you can to protect the team and keep them focused on the vision. This is why you have a Scrum Master…use them.

 

June 5th, 2012

Questions and Answers from the VersionOne Webinar – Part Two

And now for part two of the questions and answers from the VersionOne webinar.

How did you keep your pilot Agile teams from becoming special protected silos of their own? Didn’t some of the non-pilot people regard them with envy instead of emulation? EF, Technical Writer

Really interesting question. I’m not sure how everyone felt and no one came to me to directly express envy or dissatisfaction. I believe what may have helped us was to have a communicated roadmap with clear expectations for how long we would be running pilots. Folks also knew that holistic change was on its way and we had a rough timeline for when that would occur. This is not to say there wasn’t feelings of envy but I wasn’t aware of any.

Does your distributed team conduct daily standup, how do you facilitate 13 hours of difference for example or is that not a problem for you since they are in South America rather than India somewhere in Asia? PH

Our remote teams are a part of our daily stand-ups and all other Scrum sessions. As you mentioned, they are in South America so dramatically different time zones are not an issue for us. In the past, I have worked with 12 hour difference remote teams and a second stand-up would need to be facilitated very early in the morning or later in the evening or a liaison from the remote team would coordinate between the on-shore Scrum Master. Not easy but doable.

How much focus was there on the engineering practices such as TDD, C.I., Pair Programming, etc and was training provided? CW

During the transformation itself, we did not spend any serious time attempting to change engineering practices. Our focus was first and foremost on developing an organization that was healthy, collaborative, and responsive. Once we established our communities of practices in phase three, our technical communities of practice (Architect, Developer, and Tester) started to put emphasis on advancing Agile engineering practices such as TDD (test driven development) and CI (continuous integration). Not much interest within the Developer CoP for pair programming yet, but we’ll see!

How do you ensure that your offshore team uses VersionOne?  Does your license of the application extend to the offshore team or do they have to purchase the software as well? DJ, E-Learning Specialist

Our off-shore team members are fully integrated with the team and they each have a VersionOne license that we purchased. As they are considered a part of the team like everyone else the team should be holding them accountable for collaboration, engagement, and VersionOne usage.

What was the role of QA dept in your Agile world? RV, IT Program Manager

We embedded the quality assurance role directly with the delivery team and expect a very close collaboration with the developers and the team. The testers still report organizationally to a manager but their everyday role is to infuse and model a quality mindset within the whole team.

Related post:
May 31st, 2012

Questions and Answers from the VersionOne Webinar – Part One

On May 30th, 2012, I participated in a webinar hosted by VersionOne. During the webinar, I walked through our Agile transformation journey at Cars.com, how and why we selected an agile work-flow tool, and how we are currently using VersionOne.
The presentation ran a little long so the time for questions and answers was quite short. Many great questions were submitted through the chat function during the webinar so I will try to respond to as many as I can over a series of blog posts.  Here is the first batch:

What is your Scrum Master to team ratio? PH

We have 7 Scrum Masters spanning 12 dedicated product teams so each Scrum Master has two teams. We are running our intern program using Agile and another Scrum Master is working with our Ops team to implement Kanban to round the number out to 14. Two teams per Scrum Master feels about right for us.

What about employee recognition/performance reviews? What changes were made in this area during the transformation? CM, Development Manager

Great question. We did not include human resources in our Agile transformation but I wish we did. We are still using a typical performance management approach used by many companies which rates people on a 1 to 5 scale. I talked about how I handled this with our Scrum Masters in a blog post but this will need to be addressed in the future.

Does Cars.com use an in-house installation or SaaS implementation of VersionOne? KK

SaaS.  No issues.

What are some of the names of your communities of practice? AC, Senior Project Manager

Every role in our framework has a community of practice so the communities are named after each role (i.e. Developer CoP, Architect CoP, Product Owner CoP, Scrum Master CoP, etc.) You can read about how we started each community of practice here.

What is the typical timeframe in your opinion of “second stage” in an organization of 100 resources of a product company? IL, General Manager

Our phase two lasted around three months. Our agile coach, Si Alhir (@SAlhir), always quoted Leandro Herrero of Viral Change (http://www.youtube.com/watch?v=0pNsgyFJNYU): “A consultant that can’t facilitate visceral and sustainable cultural change in 6 months is not worth the money!”

Did you feel that having a coach was crucial to your transition? AM

Yes. He brought a wealth of knowledge and experience having coached and guided many organizational transformations in the past. He was able to deliver honest and direct messages that would have been challenging for an employee to deliver. Our coach also brought a proven approach to guide us along the way.

If you have any follow-up questions, feel free to ask them in the comments below.

Related post:
April 23rd, 2012

Agile Leadership Engagement Grid

As we continue our Agility transformation, we have been establishing how our leadership teams will engage with our product teams now that we have become an Agile organization. We have focused primarily on when and how organizational vision is created by senior leadership and how that vision is translated to our product teams with the director level leaders playing an important role. Our director level leaders are playing a role in our Agile framework called “Oversight” as seen in the diagram below.

Here is a description of each cell:

SENIOR LEADERSHIP/LONG-TERM  Establishing the vision for our organization and the roles in our framework.

OVERSIGHT/MID-TERM  Planning our technology and team needs based on the vision. Asking the question “Are they ready?” to our career managers to prepare for any training necessary for our people.

PRODUCT TEAM/SHORT-TERM  Delivering the vision using our Agile framework.

OVERSIGHT/SHORT-TERM  Removing impediments that cannot be resolved by the team.

SENIOR LEADERSHIP/SHORT-TERM  Encouraging and cheerleading the teams. Monitoring the progress teams are making relative to the key performance indicators established during the vision creation.

SENIOR LEADERSHIP/MID-TERM  Supporting the oversight planning and product team preparation efforts by providing funding and investment decisions.

PRODUCT TEAM/MID-TERM  Preparing to deliver by creating a road map with cross-team, architectural road map, or technical dependencies identified and accounted for.

PRODUCT TEAM/LONG-TERM  Learning the needs of our customers and future technology advancements. Ongoing product team discovery should feed the creation of the organization vision.

OVERSIGHT/LONG-TERM  Partnering between Senior Leadership and the Product Teams. Vision sharing and product learning are an important element to this collaboration.