Posts tagged ‘Scrum’

« Older Entries
July 10th, 2012

A Powerful Partnership – Product Owners, Designers, and Architects

When making our transition to Agile last year, we moved from an organization focused on delivering projects to an organization focused on delivering value through product development. As part of this move to dedicated product teams, we leveraged an approach to establish a triangle of roles used to create and maintain the vision and roadmap for the product. We call this our discovery team and it looks like this:

Agile Scrum Discovery Team

The discovery team consists of the Product Owner, Architect (or lead engineer), and a User Experience Designer. While the Product Owner is ultimately responsible for product decisions, the discovery team develops the product vision collectively by answering three questions:

Who are our users?
What are their needs?
What features will satisfy those needs?

While answering these questions and before development begins on a specific feature, the discovery team brings these unique perspectives:

Value. The Product Owner is responsible for ensuring the feature will be valuable to our customers and to the organization. Is this the right thing to do right now?

Feasibility. The Architect is responsible for ensuring the technical feasibility of the feature. This includes staff capability and technical availability. If a feature is deemed not feasible, it is added to the product roadmap (and the architecture roadmap) and developed at a time when it is feasible. Can we do this right now?

Usable. The User Experience Designer ensures our customers will have a good experience while using the product. This should include the perspective from both visual and interaction design. How will our customers react and respond if we did this right now?

By using this approach, there is an increase in:

Confidence. Often times, projects were started and deadlines announced before technical feasibility was determined. Including the technical perspective to product discovery brings a level of confidence to the team and organization when time to start building features.

Balance. The insights from each perspective provide stability to the product development process by bringing feasibility and usability into the decision-making process.

Focus. Our focus is now exclusively on our customers and their needs. It’s not just getting something done through the completion of a project, but continuously getting the right thing done for our customers.

References:
Marty Cagan “The Product Discovery Plan” http://www.svpg.com/the-product-discovery-plan/

 

Posted in product development, product discovery, Product Owner | 4 Comments »

Tags: ,
June 19th, 2012

Coaching Pull

An important dynamic of becoming a fluid and well-functioning Scrum team is when team members are continuously pulling. As opposed to being pushed or waiting to be pushed, the team is in constant motion, pulling from a queue of features that should deliver value to customers. The product owner established the queue of features by pulling from the overall organizational vision and strategy and a backlog of stories are created and prioritized.

The team pulls from the top of the backlog to decide what will be accomplished in a sprint. Team members pull from the task board throughout a sprint, regardless if its their speciality or within the scope of their role. Status is not pushed to the team but rather, they pull their progress from task walls and burn down charts.

Like many of you I imagine, I have worked on teams that were oriented to pull and I have worked on those that were pushed. This post is not meant to debate the merits of one over the other but for me and others, being a part of a team collectively pulling is much more satisfying and exciting than the alternative.

What I have experienced on teams who are being pushed (as both the pusher and pushee) are the ones doing the pushing are usually managers, supervisors, or project managers. They are expected to deliver results and they may very well obtain them but often at the cost of long-term team and organizational health.

You can always add more pushers and use brute force to get something done. Eventually the people doing the pushing will wear out and you’ll run out of pushers. Those being pushed may, at some point, have had enough of being pushed and move on.

It is also hard to change directions when in a constant state of pushing. You have probably tried moving a string around a table. Push it and it becomes a ball. Pull it and it goes wherever you want.

If you have made the decision as an organization to focus on pulling rather than pushing, here are a couple of things to consider when transforming or building your team:

Establish a compelling reason for people to pull. A pulling team requires a vision and a target – without one they will just keep themselves busy or they will create their own target until one is supplied to them.

Design your workflow system around pulling vs. pushing. Your system should make it obviously painful when someone within the organization begins to push. Pushing occurs when a common vision has not been established or communicated effectively. Many Scrum mechanics will help reveal when pushing occurs so treat any push events as impediments.

Teach and encourage the system. People will be hesitant to pull when they aren’t sure what impact their pull will have. Before coaching pull, make sure leaders and team members understand why pulling is so important to the overall health and success of the organization.

Latch on to strong pullers. You will be able to spot the strong pullers. They are the ones at the front of the line asking what’s next. They are not comfortable waiting and are often an expert within their role. They don’t mind blazing new trails for the team. If there is someone struggling with proactively pulling, have them shadow a strong puller for a couple of weeks.

 

Posted in Scrum, team dynamics, team health | 3 Comments »

Tags: , ,
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.

 

Posted in Agile, Scrum, team health | 2 Comments »

Tags: , ,
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:

Posted in webinar | 1 Comment »

Tags: , ,
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:

Posted in webinar | 2 Comments »

Tags: , , ,
May 24th, 2012

Retrospectives – A Time of Gratitude and Renewal

I believe retrospectives can be a powerful component to building an organization focused on agility and continuous improvement. But beyond asking what we can do better and what we should stop doing, the retrospective can also become a time of acknowledgment and an oasis in an otherwise stressful and demanding world.

First, the retrospective can become a setting for sincere gratitude. Time and time again I have seen team members use retrospectives to thank others for what they have done for them or how they helped them solve a challenging problem. The teammates who receive this small acknowledgement walk away with a little spring in their step. Powerful, connected teams emerge from a state of gratefulness.

There have been times during a retrospective when someone would state, “I don’t have anything to say.” or “Everything was good.”  When this happens, I would usually ask the question, “Well, what are you grateful for?” There is always a response and this often leads to others opening up to what they are thankful for as well.

Second, the retrospective can also trigger a fresh start. It gives the team a chance to reflect and learn from the past but try again with a blank slate. Not after 3, 6, or 9 months at the end of a project, if ever, but after a couple of weeks at the end of each and every sprint. We are imperfect humans, working in imperfect organizations, working with imperfect technology. Software development is hard and building teams is harder. Working in an environment in which we can naturally rebound from mistakes and inefficiencies promotes vibrancy and represents natural patterns of renewal.

Periodically, take the time at the end of a retrospective to remind the team of the amazing opportunity to renew. After capturing what changes will be made next sprint,  perhaps do something symbolic with the “let’s stop doing” cards people wrote. I wouldn’t advocate tossing them in a trash bin and lighting them on fire but you know what I mean!

Continuous improvement, a true sense of being grateful for each other, and a cadence of renewal – who wouldn’t want that work in that type of environment?

 

Posted in organizational change, retrospectives | 3 Comments »

Tags: , ,
« Older Entries