CONSCIRES AGILE PRACTICES

How Agile Projects Can Fail

By Bachan Anand / Filed under Agile, Collaboration, Inspect & Adapt, Self Organization / April 23rd, 2011

Many companies who decide to go the Agile route assume it’s their salvation for cutting time and costs on a project. That’s not always the case.

The fact that members of your leadership have agreed to switch to Agile doesn’t mean the team will be on board right away. People despise change, and often resent a third party coming in to completely turn around their systems and processes, even if it is allegedly for the best. It can be an uphill battle, and a time-consuming one.

Understand the common obstacles to ensure your team works to circumvent them:

Management is not actively promoting the benefits of Agile.
There is no Agile Champion helping the buy-in to Agile.
Leadership expects the conversion to happen quicker than is realistic.
The team members are not owning what they do.
Team members do not have a sense of urgency to make the change.

Leadership’s Role
Certainly, the person who signs the check may have influence into whether a team turns to Agile solutions, but his role doesn’t end there. It is key to have management on board, fully understanding the implications and benefits of Agile, and to cheerlead the team regularly. People follow by example.

Identifying an Agile Champion
Finding someone who fully supports the move to Agile can help the team with the transition. An Agile Champion should be someone enthusiastic about Agile who can talk to people about how it will help the project and the team. This person may field concerns and complaints and help to identify whether they are simply a resistance to change or whether there are more serious implications that need to be dealt with before moving forward. The Champion should be internal to the team; not the third party coach or consultant.

Giving it Time
Agile coaches or consultants must stress up front a realistic timeline to get a team up and functioning in Agile. If the team is on board, it may happen quickly; if not, the time and space needed to convert will stretch out. Leadership must understand that this is not an overnight process, and must support the effort throughout.

Own Your Own
In Agile, each team member has a specific role, and is responsible for a specific set of results. It is key that this team run like a well-oiled machine. Team members must own what they are responsible for.

Getting Urgent
Usually a company decides to implement Agile because of something that’s broken. Leadership wants to stop the problem and set up better processes, and they see Agile as the solution. But if all the team doesn’t feel a sense of urgency to make the transition and stop this problem from continuing, the shift to Agile will be slower and more arduous than it has to be.

Agile works, but not for every team. Without openness to change, a conversion to Agile will be futile.

The Down and Dirty on Scrum in Medical Device Development

By Bachan Anand / Filed under Agile, Collaboration, Inspect & Adapt, Scrum, Self Organization / March 23rd, 2011

By Bachan Anand and Tricia Rodewald. First published in March 2011 issue of the MPO magazine

Scrum. It’s an interesting word, no doubt. While it conjures mental images of something removed from a clogged pipe, Scrum—actually derived from the word scrummage from the sport rugby—is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. It’s used to create a collaborative approach for compressing design and development timeframes.

Recently Pro-Dex, Inc., a development and manufacturing partner for medical device manufacturers, which also has been in the processes of integrating Scrum, hosted a dinner on the topic. Keynote speaker for the event was Bachan Anand, founder of Conscires Agile Practices, a training, coaching and consulting firm for Scrum methodologies. He discussed how Scrum could be applied to improve efficiency and effectiveness in medical device manufacturing.

Anand shared his insights with Medical Product Outsourcing.

What’s the origin of the term Scrum?

Anand: It actually comes from a rugby formation. If you’ve ever watched a rugby game, you’ve seen both teams bind together in a close-knit, shoulder-to-shoulder, three-rowed formation to restart the game after the ball has gone out of play. This formation is called a scrum. The team uses the scrum formation to work as a unit to try and win the ball.

Then, in 1986, Hirotaka Takeuchi and Ikujiro Nonaka, two respected Japanese business professors, wrote a paper titled “The New New-Product Development Game” in which they compared rugby scrum to an innovative, agile approach for developing new products.

So, now, it’s referred to as Scrum.

What exactly is Scrum?

Anand: Scrum is a management framework. It’s about how you keep things focused; how you build a collaborative work culture; how you deliver the highest value to clients; and how you build customer collaboration. It’s also a mindset. Scrum emphasizes communication, cooperation, and learning between the people who are doing the work and the people who need the work done.

Can Scrum be integrated into any business or product development process?

Anand: Absolutely. Scrum’s framework is adaptable based on a company’s unique situation. In fact, integrating Scrum has completely transformed the productivity and morale in numerous companies, from Fortune 500 to small businesses, in industries as wide-ranging as software, publishing, and healthcare. It’s also improved the value they deliver to their clients and the marketplace.

What are some ways Scrum can help medical device companies streamline and compress the design and development of products?

Anand: One way is that the Scrum framework creates a much more collaborative work culture overall. Stakeholders are re-energized and workers gain more satisfaction from developing results they know are top priority for the client. People are working together more cohesively, not in silos. When this happens, there is better communication, increased productivity, and a smoother, more efficient workflow.

Another is that with Scrum, results are created incrementally in short duration. In that duration, results and efficacy of the product are inspected. The feedback from these short iterations expose issues faster so companies can adapt more quickly. This accelerates the overall design and development process and can also ensure safer, more reliable medical devices.

You’ve mentioned the Scrum “framework.” What does it look like and how is it applied to medtech manufacturing?

Anand: Like positions in scrum rugby, there are three main positions in Scrum product development: the Product Owner, the Team, and the Scrum Master. Altogether, they are known as the Scrum Team.

Let’s start first with the Product Owner. While Scrum has no project manager, the Product Owner role would be closest to that concept. The Product Owner represents the client and users of the product. They are responsible for maximum return on investment for the client and communicating what product features should be at the top of the priority list. There is one—and only one—person who serves in the role of Product Owner for the product being produced. In medical device manufacturing, this might be a product marketing manager or a product manager.

Then there’s the Team. In Scrum, the product Team is a small, self-organizing, cross-functional group of five to nine people—depending on the needs of the project. They are the ones most involved in the day to day work. In medical device manufacturing, the Team might be made up of mechanical, industrial, electrical, and software engineers, materials and planning, RA/QA, and operations.

Lastly, there’s the ever-important Scrum Master. The Scrum Master’s role is to protect the Team from outside interference; inform and guide the Team and Product Owner in the most effective use of Scrum; and help them resolve issues and remove roadblocks that stand in way of the Team achieving their goals. The Scrum Master is not a project manager and does not tell people what to do or assign tasks—she or he facilitates the Scrum process. As with the Product Owner, there should be only one person in this role who, ideally, has completed Scrum Master training. In medical device manufacturing, Scrum Masters can come from any background or discipline: RA/QA, engineering, design, testing, operations, etc.

Can you describe how the Scrum Team engages in the Scrum process?

Anand: First, the Scrum process starts with a client wanting a product made. A simple example is a medical OEM that wants a surgical tool designed, developed and manufactured. The OEM decides to contract with ABC Company (contract engineering and manufacturing) to have this done.

Following the Scrum framework, a Product Owner is designated from ABC Company. This person communicates directly with the OEM client to gain clear insight as to what the client and stakeholders (device users, executives, patients, FDA) want done, how, why, where and when. The Product Owner must work closely with the client to put together a refined, prioritized list of all the features they want their surgical tool to incorporate, what it needs to do, etc.

This prioritized client and stakeholder “wish list” is called the Product Backlog. In Scrum, only one Product Backlog exists and it’s managed and continuously updated by the Product Owner.

An important thing to note is that, in Scrum, the Product Backlog adjusts to reflect changes in the needs of the client and stakeholders.

Next, the Product Owner meets with the Team in a Sprint Planning Meeting, which is facilitated by the ScrumMaster. At this meeting, the Product Owner reviews the Product Backlog with the Team, communicating what the OEM client wants and what the high-priority items are.

The Team then focuses on estimating how long it will take to complete the highest priority items on the Product Backlog and creates their own list, called a Sprint Backlog. The Sprint Backlog is made up of the highest priority items the Team has committed to complete.

For example, the Product Backlog may have 40 items on it that the client would like their surgical tool to include. The Sprint Backlog might include the top three, four, five or six items from the Product Backlog.

Once the Sprint Backlog items are selected, the Team plans out short duration milestones called Sprints, to get the Sprint Backlog items done. Sprints allow the Team to tackle the highest priority items in manageable, “time-boxed” chunks—usually one week to 30 days.

The Team then breaks down the items on their Sprint Backlog into detailed tasks for how the Team members will complete the high-priority items.

For Example: Sprint Length—Two Weeks

This process is vital in Scrum because asking the Team what it realistically can achieve in two weeks on the Product Backlog’s list of priorities allows the Team to take ownership of the work and stay focused on completing the project at hand.

So the Team has their Sprint Backlog, their list of tasks, and their time-boxed Sprint. How do they know the work is actually getting done?

Anand: Once the Sprint has begun, the Team meets every day for a short meeting called the Daily Scrum to synchronize their work and report on challenges. The Daily Scrum is held at the same time, same place every day for 15 minutes or less.

Then, there are actually a few productive and rewarding ways the Team can manage their progress. In my opinion, the Task Board is the best tool for this. The Task Board consists of different columns: To Do, Work in Progress, and Done. It can also be good to add a History column (for completed projects) and a column for the full Product Backlog to give an overall picture of the work planned for the Sprint and full completion of the project.

Once the Team members are ready to take on their specific task, this visual display makes it easier for the cross functional Team to self organize and stay focused. That, in itself, provides great potential to transform the way we approach work.

As the Team makes progress with the Sprint, the Task Board offers a transparent view of the work that is completed by the whole Team and gives them get a better picture of what needs to be completed to meet the Sprint commitment.

Another approach is that the Team members update their estimate of the amount of time remaining to complete their current Sprint Backlog tasks. Someone then adds up the hours remaining for the Team as a whole and plots it on the Sprint Burndown Chart. The Sprint Burndown Chart also can be a helpful visual to see how close the team is to achieving goals and if adjustment is needed.

What happens after a Sprint time-box ends?

Anand: Then it’s time for the Sprint Review, which is an opportunity for the Team to show the Product Owner, the client, management, users, and other stakeholders what’s been created during the Sprint. It creates better ownership because the Team proudly presents what it has completed.

For example, for a two-week Sprint for a surgical tool, Teams most likely wouldn’t deliver a full prototype. But they can show parts of that prototype at the Sprint Review. The most important element to a Sprint Review is the dialogue that occurs at the review between the Team, the Product Owner, and other stakeholders. This focused conversation is what supports a collaborative, engaged company culture. After the Sprint Review, the Product Owner may update the Product Backlog to reflect any new changes, insights, and priorities.

The Team then moves on to the next Sprint, starting the process over again (Sprint Planning Meeting, Sprint Backlog, time-boxed Sprint, Daily Scrum, Sprint Burndown Chart, Sprint Review).

Is there an opportunity for the Team to reflect on what may not have worked to improve forthe future?

Anand: Definitely. In Scrum, this is called the Sprint Retrospective. This takes place at the end of each Sprint when challenges and triumphs are at the top of the mind. Retrospectives are a key part of making changes and creating improvements. Basically, in a Sprint Retrospective, the Team answers three questions: What worked this Sprint/iteration? What didn’t? What could we do better next time? And then goals for improvement are made by the Team.

What are some of the challenges with a sequential product development strategy?

Anand: First, stakeholders are not involved until late in the process. If changes are needed, they can be very disruptive and difficult to implement, sometimes even causing the project to be scrapped or significantly delayed. Another is that re-visiting a phase once it is completed is rarely done. This often fosters an adversarial relationship between the people handing work off from one phase to the next. Also, people simply can’t predict the future—regulations change, competition brings a new, similar product to market first, financing changes, etc. Planning, designing, and documenting everything up front leaves little room to respond to these changes if necessary.

What are some noteworthy solutions Scrum offers to medical device manufacturers?

Anand: Though Scrum can be a significant shift in the way medical device manufacturing is done, the reality is that Scrum leads to happier clients, as they are now part of the process.
Employees are also more satisfied as they are no longer just working for the sake of working. There’s also less waste because Teams are focused on what the client wants. In turn, better products are developed that improve healthcare and save lives.

Final thoughts?

Anand: Change is hard, but change is inevitable. The real question is: Do you want to change for the better? Scrum is a framework in which to do that.

Agile Retrospectives: Hey ScrumMaster, where’s your agenda?

By Erin Beierwaltes / Filed under Agile, Inspect & Adapt, Scrum / March 10th, 2011

Do you feel like your retrospectives are valuable? Does your team complain about having to do them? The basic scrum approach says “though shalt have a retrospective”, but unfortunately often people aren’t aware of the tools and approaches they could use to make them valuable. First of all, I always like to ask people if they are getting real “Action Items” at the end of their retrospective that they treat as deliverables during their sprint that are looked at again at the next sprint retrospective.

This isn’t a time to complain or have a “lessons learned”. What does that even mean? I learned my lesson?! How will you prove to me that you learned your lesson? Have about making a working agreement or trying a specific approach and actionable behavior during the next sprint?

It should be obvious that the simple set of questions,

What went wrong?
What went right?
What can we change?

..doesn’t guarantee that you really get the participation and action items needed to make great improvements in your process.

A SAMPLE AGENDA

Here is a sample Agenda based on

Retrospective (60 min) 10:30 to 11:30

1. GATHER IDEAS (10:30 to 10:45)

a. Draw 4 quadrants and label each with one of the following categories

i. Start
ii. Stop
iii. Continue
iv. Shout-Outs

b. Brainstorm topics/comments individually in each area until 10:45

c. Group any comments that are similar

2. REVIEW (10:45 to 11:15)

a. Review each “Start” group/idea and any additional action items or working agreements that could help with the idea (make a new post it note for each)

b. Review each “Stop” group/idea and any additional action items OR working agreements that could help with the idea (make a new post it note for each)

c. Review each “continue” and take note of what is working well for your other team members (hopefully there aren’t any action items here, since we are continuing good practices)

d. Read the “Shout-Outs”

3. VOTING (11:15 to 11:20)

a. Move each unique action item to one area for clear voting

b. Give each team member 5-10 stickers for voting

c. Vote

4. WRAP UP (11:20 to 11:30)

a. Choose the top 2-4 action items and decide WHAT the criteria and expectations are to ensure they are completed or followed. (ex. Don’t just say you want to do pair programming more. Say exactly WHAT you will do to improve it and show progress at the end of the sprint)

Final Comments

I try new things every sprint. Watch for how the team is using what they learned. Look for items that could be discussed in the retrospective. Choose activities and approaches that help the team find ways to improve without your direct suggestions. The retrospective is one of the most important times for the ScrumMaster to guide the team towards making their own decisions and improvements and I think we can all agree that when its their own idea, they acceptance will greater.

Originally published by Erin Beierwaltes in Agile in Action.

The Joy of Doing

By Bachan Anand / Filed under Inspect & Adapt, Scrum / January 24th, 2011

Dreams are Exciting, Plans are Exhausting,
Attaining is gratifying – Doing is Joy!

How often have we come across people who keep going on and on about creating something beautiful and rare that the world has not yet envisaged, but never take a single step to bring themselves closer to achieving it?

All of us have beautiful dreams, but how many of us have really been able to put them into practice? There is no end to the plans one can make, for the masterpiece one aspires to create.

Contemplating a vision without putting any significant effort into realizing it, in truth, burdens us more than the effort required to accomplish it does. The idea we spent hours fantasizing on sometimes chokes us as it struggles to escape, and unless we give life to it, we will find no peace!

The same is true in the context of work as in life. Sometimes, despite the huge amount of time we spend on exhaustive and detailed planning for a project, trying to foresee the hurdles that could crop up, we still find ourselves unprepared for the uncertainties, inconsistencies, feedback and other factors that creep in during the actual implementation. The time spent on planning remains unjustified, and the time spent on implementation, insufficient.

Very often we are denied the joy of a completed task because we do not check to see if we’re on track. After all the time spent on planning, at the final stage, we realize how far we are from the product we dreamed of making, or how low its quality is. The end result? No satisfaction from work.

Scrum, the most popular of the Agile methods, seeks to remedy this situation by considering a subset of the entire project at a time and inserting checkpoints at frequent intervals in the life of the project, using Plan – Do – Inspect – Adapt cycles. ‘Plan’ takes into consideration only a small set of features or aspects, thus providing more time for the ‘Do’, the actual implementation. After ‘Do’, it is time to take stock of the lessons learnt (‘Inspect’) and check coordinates to see if we have strayed from the goal, make corrections or modifications in our approach(‘Adapt’). Then the cycle repeats. In Scrum, these steps are known as Sprint Planning, Sprint, Retrospective and Sprint Review.

The Scrum way of working takes into consideration the human element – satisfaction from work inspires us to be productive, without compromising quality. The essence of Scrum works at a deeper level alongside human thought process and emotions. There is contentment in doing things, because of the impact of working in the Scrum fashion.

So what does this method help achieve?

Quite simple.
The happiness that comes from creating your own masterpiece.
The satisfaction of making a product of excellent quality.
The ecstasy that comes from a work well done.
The Joy of Doing.

Agile Coach Exchange

By Bachan Anand / Filed under Collaboration, Inspect & Adapt, Scrum, WORK is GOOD / December 29th, 2010

Agile conferences, user groups (LinkedIn, Google, Yahoo, etc), Twitter feeds…What are all Scrum/Agile leaders, managers and coaches craving, nay, wildly seeking? Case studies. Yep, just the opportunity to get a tiny glimpse of Agile processes in other organizations. When you’re trapped on your tiny island of Agile adoption, it’s tough to be innovative and discover Agile best practices for your organization.

By the same token, Agile has enormous benefits at the enterprise level: increased responsiveness, decreased costs, higher quality, etc. Now just find a seasoned Agilist to get the ball rolling and keep it rolling. Even the Scrum Alliance realizes the quality and quantity of experienced Scrum and Agile professionals is quite an issue. As an organization, what can be done to identify and nurture key players in a successful Agile adoption?

Is there one, magical solution? While coaching circles are undeniably valuable, there is no substitute for face to face interaction. Our answer is an exchange program for Agile champions, leaders and coaches.

Participating Agilists would be paired based on needs, wants, and experience. In turn, the participants would spend a day or two shadowing or being shadowed, no proprietary business, just a peek into a different adaptation of Agile. The exchange would provide an opportunity for leveraging combined Agile experience.

Individuals

Beyond building a warm and fuzzy sense of Agile community, what’s the benefit for individuals? Well, what are the alternatives? Honestly, in the realm of education, not much of value exists beyond CSM and CSPO. What does exist is not often readily available and takes valuable time away from coaching work. As far as mentorships go, it’s difficult to find a mentor when not seeking CSC or CST designation.

Participating in this program will give leaders and coaches the opportunity to give and receive third party feedback, something radically different from the observations, suggestions and criticisms of mangers, team, etc. Through the observation and feedback process, agile best practices would diffuse through the Agile community.

Organizations

Staying enthused and engaged as an individual Agilist is all well and good, however, participants’ work places must agree to the exchange. So what are the advantages for Agile organizations? Exchange coaching is an opportunity for organizations to grow successful Agile champions and coaches, especially valuable in this environment of seasoned coach scarcity. Save the big price tag of a crew of Agile consultants, and give your coaches/leaders/Agile managers what they want: peer to peer interactions.

Conclusion

It’s time to stop searching for case studies and actually LIVE Scrum. After all, isn’t Agile about taking ACTION? Not sitting through static presentations or reading an outdated anecdote…

If you are ready to stop reviewing case studies and start LIVING Agile, fill out the survey below or contact Bachan Anand via phone at 949/232-8900 or email at bachan.anand@conscires.com.

Create your free online surveys with SurveyMonkey, the world’s leading questionnaire tool.