Skip to content

Feed aggregator

When Will We Complete Our Agile Transformation?

Leading Agile - 1 hour 17 min ago

People tend to ask me the general question of how long it will take to complete an Agile transformation.  Unless I’m responding to my son, in which the answer would be “5 more minutes”, my answer would be “it depends”. It’s just the reality, based on so many variables. At LeadingAgile, we describe the journey of a transformation as successfully getting a pilot group (expedition) from basecamp to basecamp. We then follow with other groups, when the path is clear and well maintained.

Let’s say you’re planning a long hike on the Appalachian Trail or climbing Mount Everest (transformation analogy). To calculate the time to complete the journey, the first thing I would look at on the trail map is the distance (to my final destination goal), then the elevation changes to my basecamps or resupply points, then I would look at the weather conditions.

Trail Map

Look at the graphic at the bottom of our compass page to visualize what I’m saying.  If you know where you are and know where you want to be, with mountaineering you are fortunate to look at the map, see your latitude, longitude, and elevation, and know if you’ve made it to your destination.  With Agile transformations, the coordinates on a map are actually your adoption levels in four of the five competency areas defined in our assessments: Defining the product, planning and coordinating, delivering solutions, and continuous improvement.  We’ll talk about the fifth competency area, organizational enablement, in a little bit.

Basecamps

If you were climbing Mount Everest, there are two basecamps, one on each side of the mountain. They are basic encampments for providing supplies, shelter, and communications for persons engaged in the trek. Supplies are carried to the basecamp by sherpas or porters (in our case it will be one or more of our guides). The criteria to reach each basecamp is different, depending on the destination. Using our compass, we know where you are, know where you are going, and know what gear you are going to need.  Though I know you want to reach your final destination, focus on reaching the next basecamp safely is critical.  Your transformation will fail, if you can’t get your team safely to a basecamp.

Weather Conditions

I see going from basecamp to basecamp as a change of location and elevation or a change in behaviour and outcomes within your organization.  The expedition will have to get used to operating at different elevations. But weather conditions are much more unpredictable.  If the weather conditions were unfavorable, and I have a long trek ahead to the next basecamp or summit, it could make an expedition harder than it need be or downright impossible. How do I know the current weather conditions? In our assessment, I use Organizational Enablement.

Organizational Enablement

In order for teams to improve in the other competency areas (reach basecamps), they should also improve in areas of organizational enablement.  If an organization refuses to form teams, provide a supportive organizational context, or ignore a series of other elements, it would be like walking into a blizzard in summer.  It’s going to slow you down to a crawl or stop you dead in your tracks.

In order for change to occur in your organization, you must enable it to happen.  Want to know how long it will take to complete an Agile Transformation?  I think you need to listen to your guide but you also need to control the weather.

The post When Will We Complete Our Agile Transformation? appeared first on LeadingAgile.

Categories: Blogs

ScrumImpulz, Bratislava, Slovakia, April 29 2015

Scrum Expert - Tue, 03/03/2015 - 18:43
ScrumImpulz is a one-day conference focused on Scrum that takes place in Bratislava, Slovakia. Local and international experts share their practical experience about the adoption of Agile approaches in software development projects. In the agenda of the ScrumImpulz you could find topics like “Management 3.0 – model for agile leaders”, “The worst fails that can occur in our agile team and how to deal with them”, “Global challenges require responses. People and teamwork are the best one” and a case study on Agile in the software development department of an international ...
Categories: Communities

From Software Development to Problem Solving

Scrum Expert - Tue, 03/03/2015 - 18:35
Agile and Scrum short iterations should provide software development organization with quicker feedback cycles and help them shifting from building the product right to building the right product. In their book “The Lean Mindset”, Mary and Tom Poppendieck provides an original perspective on this issue. What’s next is to stop thinking about software development as a delivery process and to start thinking of it as a problem-solving process, a creative process. Time and again we run into software delivery organizations – IT departments operating as cost centers and software firms working ...
Categories: Communities

Four Tips for Managing Performance in Agile Teams

Johanna Rothman - Tue, 03/03/2015 - 14:32

I’ve been talking with clients recently about their managers’ and HR’s transition to agile. I hear this common question: “How do we manage performance of the people on our agile teams?”

  1. Reframe “manage performance” to “career development.” People on agile teams don’t need a manager to manage their performance. If they are retrospecting at reasonable intervals, they will inspect-and-adapt to work better together. Well, they will if managers don’t interfere with their work by creating experts or moving people off project teams.
  2. The manager creates a trusting relationship with each person on the team. That means having a one-on-one weekly or bi-weekly with each person. At the one-on-one, the manager provides tips for feedback and offers coaching.  (If the person needs it or wants it from the manager.) The person might want to know where else he or she can receive coaching. The manager removes obstacles if the person has them. They discuss career development.
  3. When managers discuss career development, each person needs to see an accurate view of the value they bring to the organization. That means each person has to know how to give and receive feedback. They each have to know how to ask for and accept coaching. The manager provides meta-feedback and meta-coaching.
  4. If you, as a manager, meet with each person at least once every two weeks, no problem is a problem for too long. The people in the team have another person to discuss issues with. The manager sees the system and can change it to help the people on the team.

Now, what does this mean for raises?

I like to separate the raise from the feedback. People need feedback all the time, not just once a year. That’s why I like weekly or biweekly one-on-ones. Feedback isn’t just from the manager to the employee; it’s two-way feedback. If people have trouble working in the current environment, the managers might have a better chance to change it than an employee who is not a manager.

What about merit raises? This is tricky. So many managers and HR people continue to think one person is a star. No, on well-functioning agile teams, the team is the star—not individuals. You have options:

  • Make sure you pay each person at parity. This might not be trivial. You need expertise criteria for each job level.
  • When it comes to merit raises, provide a pot of money for the team and ask them to distribute it.
  • Distribute the merit money to each person equally. Explain that you are doing this, so people provide feedback to each other.
  • Here’s something radical: When people think they are ready for a raise or another level, have a discussion with the team. Let the team vote on it.

Managers have to not get in the way when it comes to “performance management.” The people on the team are adult humans. They somehow muddle through the rest of their lives, successfully providing and receiving feedback. They know the worth of things outside work. It’s just inside work that we keep salary secret.

It might not fit for you to have open-book salaries. On the other hand, how much do your managers and HR do that interferes with a team? You have to be careful about this.

If you reward individuals and ask people to work together as a team, how long do you think they will work together as a team? I don’t know the answer to that question.

Long ago, my managers asked me to a “team player.”  One guy got a huge raise—and I didn’t, although I had saved his tush several times—I stopped working as a “team” member. I got my big raise the following year. (Year!) This incongruent approach is why people leave organizations—when the stated way “we work here” is not congruent with the stated goals: agile and self-organizing teams.

What do you want? Managers and HR to manage people? Or, to lead people using servant leadership, and let the teams solve their problems and manage their own performance?

If teams don’t know how to improve, that’s one thing. But, I bet your teams do know how to improve. You don’t have to manage their performance. You need to create an environment in which people can do their best work—that’s the manager’s job and the secret to “managing performance.”

Related posts:

 

Categories: Blogs

3 Thinking Tools for Minimizing Dependencies Between Products

Leading Agile - Tue, 03/03/2015 - 11:00

In my post about how to form teams, I talk about products… not in their monolithic, holistic state… but as a subsystem within a larger integrated solutions architecture. In other words, big products are just series of small products that work together in an integrated fashion. Each of these smaller products have a backlog, a team, and the team can produce a working, tested, increment of the product on regular intervals… you get the idea.

There are tons of reasons that make this approach a great way to build software. Code ownership is less complex. Branching strategies simplify. We have a much smaller group of people interacting with the code base and business logic, etc. The downside of this approach is that you’ll probably have to coordinate requirements dependencies between teams and you’ll often introduce sequencing dependencies between sub-systems.

We’ve established that dependencies are evil, so let’s talk about a few strategies for breaking them or at least minimizing their impact:

1. To fully break dependencies between products and shared components, products can only commit to features built on capabilities already present in the shared component. Products can request new capabilities from their component teams, but those requests go into the queue and get done when they get done. It’s as if the component team was a separate company having to balance the needs of multiple customers to provide the most value to as many people as possible. The product team can request new capabilities, but they cannot mandate them or set a date.

2. To minimize dependencies between products and shared components, products can only commit to capabilities that are on the near term roadmap of the component team. In this case, if the component team is stable and has a known velocity… and they can reliably size your request… and let you know where you fit into their backlog… it might be safe to bet on the fact that nothing will change and you can get your capability added in the sprint or release that the component team has planned. This is only safe a sprint or two or maybe a release out.

3. To manage dependencies between products and shared components, products inject capabilities into the component teams backlog and force a dependency. This is the most risky of all strategies, but could possibly be necessary in some circumstances. In this case, each team better have a stable backlog and a known velocity and be able to make and meet a commitment with a pretty high level of confidence. If this is an exception to the rule, and only used as a last resort, you might be able to get away with this occasionally. Again, this is the least desirable approach.

So in short:

1. Never commit to a feature the depends on a component capability that does not exist
2. Sometimes commit to a component capability on the near term roadmap
3. Rarely commit to a component capability with a hard date driven dependency.

Let me know if you have any questions or comments. I think this is going to be a challenging concept for many folks. I’m interested in your thoughts.

The post 3 Thinking Tools for Minimizing Dependencies Between Products appeared first on LeadingAgile.

Categories: Blogs

Product Owner Survival Camp, Vienna, Austria, March 19-20 2015

Scrum Expert - Tue, 03/03/2015 - 08:55
Product Owner Survival Camp in Vienna is a two days of practical workshops of Product Owner. Four distinguished experts will teach you how to apply the right techniques at the right time to get the full benefits of Agile software delivery. In the agenda of Product Owner Survival Camp, Vienna you can find the following workshops ” Discover to Deliver” with Ellen Gottesdiener, “Impact Mapping” with Gojko Adzic, “The Anatomy of a User Story” with David Evans, “Build/Measure/Learn with Story Maps” with Christian Hassa. Web site: http://www.techtalk.at/TechTalk/Veranstaltungen/Product-Owner-Survival-Camp-Vienna-(AT) Location for the Product Owner Survival ...
Categories: Communities

The Evolution of Teams

Leading Answers - Mike Griffiths - Tue, 03/03/2015 - 07:19
My other workshop submission for the Agile 2015 Conference is titled “The Evolution of Teams” and examines one team that stopped doing the traditional agile practices is more agile than ever. Agile practices such as daily stand up meetings, sprint... Mike Griffiths
Categories: Blogs

Holy CRAP I have to do THIS ?!?!

Mike Vizdos - Implementing Scrum - Mon, 03/02/2015 - 19:22

 July 23, 2007)

Are YOU saying this TODAY about Scrum (or Agile)?

Or… do you know someone who is saying (OK… maybe THINKING) this?

This posting is for you (or send it to someone who you see freaking out about having to DO this).

If this is NOT you… please move along (or read this and be happy you are not here today).

First things first.

Scrum is nothing new.  Neither are the concepts around “Agile.”

Scrum does NOT solve your problems.  Sorry.

Scrum is not THE solution.  Sorry.

Scrum is a framework that actually EXPOSES all the dysfunctions in your organization; this could be a team, division, company, NGO, government, non-profit, or ????.

What does this mean if you have been told that you MUST move to an Scrum and Agile?

Some naysayers will tell you to bend over and kiss your ass good-bye.  It’s not THAT bad.

Many people have been “burned” by attempting to try Scrum and Agile in an environment that was not ready.  Read more in this blog about some of the stories of people who have AND what people have done to avoid that situation.

What can you DO?

1)  Learn from others.  This requires conversations with people.  Some of them may be tough.  You are not re-inventing the wheel here. Get a mentor or coach (inside or outside your organization).

2) Get some training for yourself, your team, and your stake holders.  Get buzzword compliant at a minimum.  Buzzword compliance does not mean you will be successful.  This takes time and training can show you what’s coming.

3) Is your first “pilot” project in RED already? Identify someone with enough political capital to take fire cover for you.

4) If you cannot identify a ScrumMaster, Product Owner, and a Dedicated TeamSTOP.

5) Get ready to Focus and #deliver.  Remember this is not an “IT” thing — it involves people in your organization working together.

That’s IT?  You’ve GOT to be kidding….

This five step list above seems pretty simple.

Start with simple.

Start small.

Focus. #deliver

It’s not as bad as it may look at the moment.  It requires a change and if you are not ready to change, please STOP and just keep doing whatever you are doing today (it’s gotten you this far, right?!?).

Questions?

Free.  No sales-pressure.

Here is the thing… I am not a mind reader.  I DO have experience being where you are today and I help people navigate this daily (and, I also use these techniques in running my own business).

It starts with a conversation between two people.

I am available for that conversation (or find someone who is open to doing this with you!).

Let’s Talk

 

NOTE:  This comic strip was originally published on July 23, 2007 under the topic of: “ScrumMaster = Snake Oil Salesman?“.

Try learning some new techniques too (see my last posting on NVC and Scrum).

Categories: Blogs

What It Takes to Grow Great Teams

Scrum Expert - Mon, 03/02/2015 - 19:20
For best results from Agile, you need a solid team. If you belong to, manage, or lead an Agile team, you’ve probably seen that process alone doesn’t translate to great results – and that having a cross-functional group of 7 +/- 2 “resources” doesn’t either. Instead, what makes Agile come to life is the team’s motivated, engaged individuals who communicate, collaborate, and respond effectively. In many organizations, teams rely on their leaders and managers to help them grow and become stronger. But how do Agile leaders and managers help their teams? ...
Categories: Communities

Understanding the Indian 'Yes'

Scrum Breakfast - Mon, 03/02/2015 - 12:12
My experience with the word 'yes' in India is that it doesn't seem to mean what I think it means. And the word 'no' does not seem to exist.Doing business with India for me has always been a somewhat strange experience. As native speaker of North American English, there is a language barrier. Yes, it's English, but.... I was never really sure when negotiating with my business partners whether they were really going to deliver what they said they would. Often there would be substantial differences between what I thought we had agreed to and what was actually delivered.

Since I agreed to a four city tour in November of Scrum Trainings, I thought this would be an excellent opportunity to explore what yes really means, and why it remains such a stumbling block. What did I find out about 'yes' and other aspects of Indian culture?
Raising the questionMy Scrum courses devote substantial attention to working agreements. At the start of each course, I facilitate a discussion among the participants. “What agreements do we need among ourselves so that we can work together effectively between now and the end of the course?” The participants propose their topics, and then agree to concrete actionable proposals. I might add a topic or two. Sometimes we have to modify the proposal before we can come to an agreement that everyone can really support.

Agreements among the participants make for an effective course and agreements among colleagues are an excellent tool for transforming corporate culture. You can't change corporate culture directly, but you can influence your meeting culture quite strongly, simply by making working agreements with your colleagues. This in turn influences and changes your corporate culture.

Nicolas Jene, one of my participants last October was retaking the CSPO course he had taken a year ago. Back then, we had made a number of working agreements, including being on time and ready to go after breaks, devices off or on silent, no crosstalk, the attention protocol, how to deal with questions, etc.
People are the same everywhere...Nicolas noticed that the working agreements this time around were essentially the same as the agreements as in his last course, so he asked, 'Are the working agreements always the same? Even in different cultures?” I thought back to my the last year of courses in Switzerland, in Russia, in Portugal, in Italy, and in Texas, and replied, 'yes, pretty much. But I am not sure how that will be when I get to India, because the culture there is quite different compared to where I have been before.

So in all of my India courses, I facilitated the same discussion. What do we need to work together effectively?

All of my participants in India asked for and agreed to more or less the same the agreements, just like at every other place else I have been to. They did have some novel suggestions, but the topics and actual agreement were essentially the same.

My conclusion? People are the same everywhere. They want the same things from each other. They need the same things to work effectively: Focus, Commitment, Courage, Openness and Respect. Sound familiar? These are the Scrum values. You find all of them reflected in people's working agreements.
But cultures are differentIf people are the same everywhere, does that mean everyone thinks alike? Of course not! Case in point: during my last product owner class, I showed Henrik Kniberg's fantastic video “Agile Project Ownership in a Nutshell” (watch it here). One highlight of this video is the importance of saying 'No.' “Pat [the product owner] practices [saying No] every day in front of a mirror.” After watching the video, the class wrote down their “Eureka!” moments of what they would take home from the video. Most of the participants found that 'No!' was a highlight of the film. “We are allowed to say no!?” “We're expected to say no!?” “Wow!”

One person, of Indian origin, had a completely different lesson from the video: “Sometimes it is better to say yes and prioritize down.” What?! That was exactly the opposite of what Henrik's video was trying to say, or so I thought. I even asked him about it. Yes, that was his a-ha! moment. After getting past my disbelief, I reflected on why his answer might have been different from mine and the others.

If the inputs seem the same, but the outputs are different, then there must be some other inputs I don't know about. I call these inputs 'culture' and I decided I wanted to explore that further during my trip to India.
Why is 'no' so difficult to say?At each course in India, during the section on working agreements, I introduced the topic of yes and no, and explained why I thought there was an issue. My participants agreed that this misunderstanding occurs quite regularly when working with western companies. So I invited the participants to discuss in pairs why saying no is so difficult, then report back on to the group.

To my surprise, there was no hesitation to discuss the issue (though I had done a lot to lower the social risks in the room before asking question). The opinions of all four classes – over 100 people – centered on three issues:

  • Our upbringing discourages us from saying no. It is impolite to say no.
  • If I say no (to the customer), my company might lose the business.
  • If I say no (to a manager), I might lose reputation and risk losing my job.

In short, it's about fear. It's about the challenges of living in a developing nation. It's about the fear of becoming part of the 60% of the population that lives on $2/day or less. Saying yes is an accommodation. You may lose the business or your job later, but you do have it today, and that is perceived as much lower risk than saying no right away. Given that upbringing appeared so often in the list of reasons, it looks like the accommodation is deeply ingrained in the society.
What does 'yes' really mean?What does 'yes' really mean in India? It depends. It might really mean yes. It might also mean “I'm saying yes to satisfy your expectation” (but without committing to actually deliver on the expectation). More likely, it means, “I'm going to do my best, but there may be outside forces that I cannot control which will prevent me from succeeding.”
How to bridge cultural differences?I don't pretend to have the definitive answer to this question. I found being in India, talking face to face with people and learning to recognize their body language were both very helpful. I found it easier to work with people while I was there than over the phone from Switzerland.

Is there really a conflict between being polite and setting realistic expectations? I think this is a false dilemma. Henrik Kniberg pointed out that Autonomy and Alignment are not opposites, but independent of one another. People can be aligned and autonomous. Steve Biddulph wrote that parents can be both firm and loving with their children. How can you set realistic expectations and be polite? I think that is a fair question for any team to ask of itself.
Conflict avoidance is not evilMany facilitation techniques avoid using the word No. In a retrospective, we first identify possible topics for improvement. Then we identify the most important items, and say yes to a few of them. We don't actually say no to anything. Just yes. Dot-voting is classic consensus-building tool. Identify the most important, start there. And Rod Collins' Work-Thru also focus on identifying where we agree, so we can start here, and deferring points of conflict until later, when trust is higher and the situation is clearer. (Read more about Work-Thru's...)

Are there patterns here which could be applied for other kinds of collaboration? I have seen evidence that working agreements can be extremely effective at transforming corporate culture. Can working agreements be the basis for bridging cultural differences within a project? I believe so. You create your own culture through your working agreements (among other things – good stories are vital!) within your project so that you and your on-shore and off-shore collaborators can work together effectively.

Finally I believe that one day, people in India will let go of their fear. It is not weakness that makes people afraid, it is fear that makes them weak. India has strong abilities and great prices. There will always be a demand for that combination. If this customer gets away, there is always the next one. Once people realize they don't need to be afraid, they will have the courage to say no and to say a yes that really means, Yes!
Categories: Blogs

Bend the Spoon

Leading Agile - Mon, 03/02/2015 - 11:00

Bend the spoon is a phrase we use quite a bit here at LeadingAgile. I don’t want to hear what’s happening, I want to hear what we need to make happen… and what we are doing to make it happen. I don’t want to hear why we can’t do something, I want to talk about what we are doing to make reality conform to our will.

If it’s impossible… bend the spoon.

Some people are wired to bend the spoon, some are not. When I walk down a busy sidewalk, I kinda expect traffic to flow around me. When my wife walks down the same sidewalk, she dodges the oncoming traffic. My wife sees the world as a set of rules that have to be followed. I think that rules are made to be broken.

If you believe you can bend the spoon in your organization, you are going to have a much greater chance of actually making change. If you see your organization as a set of immutable laws, laws set in motion by powers that are beyond your control, it’s going to be much more difficult.

Bending the spoon isn’t about imposing your will on the organization… it’s about believing that change is possible. That somehow, someway… all the crap that is getting in the way of really adopting agile can be changed. If you don’t believe you can change your organization and decide to change agile to accommodate dysfunction… you are going to fail.

Bend the spoon.

The post Bend the Spoon appeared first on LeadingAgile.

Categories: Blogs

Eat Risks for Breakfast, Poop Awesomeness All Day!

Leading Answers - Mike Griffiths - Sun, 03/01/2015 - 00:03
I have submitted a presentation for Agile 2015 Conference about team based risk and opportunity management that may well get rejected based on its title alone! It has always been a good practice to engage team members in the estimation... Mike Griffiths
Categories: Blogs

Fueling Delivery Teams

Leading Agile - Fri, 02/27/2015 - 20:52

I’ve started using an analogy to illustrate the importance of product owner teams in larger organizations.  When working with organizations to do an agile transformation, almost always, a tiered model is used for scaling across the organization. The model looks something like this:

tiered-model

The top tier is portfolio management which is responsible for investment decisions and what initiatives continue to move forward. The middle tier is representative of the Product Owner role in Scrum and is where we often create program teams, sometimes called product owner teams. The bottom tier is where stable cross-functional teams reside that are delivering increments of value in some cadence such as every two weeks.

Let me describe this engine analogy to see if it resonates with you. Stable Engines

I think of the delivery tier as the engine of the organization. Each delivery team is designed to operate at a sustainable pace in a very predictable manner. If we think of each team as an engine then we may find some operate at 2500 RPM, others 3500 RPM, regardless, they each operate at a RPM that is sustainable. If we can operate with little variance then we can start to become predictable and make promises on what can be delivered over time. If a team is running at 2500 RPM then I can determine how far that team will travel if that engine powers a car.

But, if we push the engine past a sustainable pace, or have them operate past the redline, then the engine becomes stressed, will wear out more quickly, and likely fail to deliver as expected and certainly become unpredictable.

Fuel for the Engines

Product owner teams represent refineries responsible for providing good fuel. They must understand the business goals and problems to be solved, collaborate with delivery teams to define capabilities to build, and further decompose those into clear backlog items that provide clean burning fuel needed by the engines.

Provide bad fuel – the teams sputter and are unable to run at a consistent RPM. Bad fuel will not allow us to make promises to the market or our customers.

Drilling Locations

I haven’t completely vetted this out in my mind, but when thinking about portfolio management I believe this is where we are making investments on where to drill for crude oil. We increasingly learn more about the potential initiatives, collaborate with the product owner teams, and possibly delivery teams to progressively gain more knowledge so we can make funding or cut decisions about where we will invest.

Wrapping Up

This analogy seems to resonate when I’ve used it over the last few months to describe the responsibilities of delivery teams and product owner teams. Turning crude into clean burning fuel is a big job and really highlights the challenge most organizations have in providing clarity to their delivery teams.

I would love to get your thoughts on how I’m thinking about this.

The post Fueling Delivery Teams appeared first on LeadingAgile.

Categories: Blogs

What’s the Best Conference Talk You’ve Heard?

Rally Agile Blog - Fri, 02/27/2015 - 15:00

The tech industry has long used conferences to share ideas, products, practices, and news. In this era of TED talks, YouTube, SlideShare, and livestreaming, it's easier than ever to be in the audience when thought leaders take the stage.

The best conference talks -- even if they’re virtual -- elicit a reaction that’s visceral: they make you think and act differently. Whether it’s a jarring statistic, or a humorous anecdote, or a charismatic speaking style, something about the best talks stays with you long after the talk has ended.

Ring a bell? That’s the kind of talk we’re after for RallyON 2015. Here are some talks from last year’s RallyON that people still talk about today.

What’s the most intractable, inefficient, and slow-moving organization you can think of? If you said the US government, you’re probably not alone. As we learned in this talk by former Assistant Secretary and CIO of the Department of Veterans Affairs, Roger W. Baker, implementing Agile at the VA had powerful and mind-changing consequences.

  • The department’s success rate for IT programs went from 30% to 83%.
  • The VA returned $373 million to the US Treasury budget.
  • It deployed the Veterans Benefits Management System—a $700 million program that completely replaced a paper-based system—six months ahead of schedule.

It’s rare to get a peek at how large, publicly traded enterprises do things under the hood; it’s even rarer to hear them talk about both what’s working and what’s not. So when Wendi Nagy, Program Director at Comcast, assembled a team (PMO Director Paul McGregor and Agile Coach Janelle Brunke) to share the lessons learned in the company’s Agile transformation, people listened.

  • What they did right: standardizing iteration length and using common user story formats in a single Rally workspace.
  • What they did wrong: a “never say no” culture that resulted in too much WiP.
  • What’s working: instead of delivering in silos, teams demo features to internal and external clients at the end of iterations -- earning them a great reputation for delivering.

You’ve probably heard or seen a conference talk that made you think twice, made you want to share it with everyone you know, or made you change how you do things. What’s the best one in your book? What would you like to hear at RallyON 2015? Submit to our Call for Content and tell us more in the comments below.

Rally Software
Categories: Companies

Gastblog: Ervaringen met Agile en Scrum Certificeringen

Ben Linders - Fri, 02/27/2015 - 11:02
In deze gastblog deelt Erik Philippus van ImprovemenT zijn ervaringen met diverse agile en Scrum certificeringen. Continue reading →
Categories: Blogs

What Is An Agile Team and How Do You Form Them?

Leading Agile - Fri, 02/27/2015 - 11:00

An agile team is not just any random group of people. An agile team is not a group of business analysts doing a daily standup to coordinate their work. It’s not a group of developers that meet every other week to do sprint planning. It’s not a project team with folks matrixed across two or more other agile teams.

An agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product. These people are dedicated to the team, and as a rule, do not move between or across teams as demand ebbs and flows.

I’m going to suggest that the very definition of an agile team… a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product… is getting in the way of forming agile teams, mostly because we misunderstand what a product actually is.

In the small, this guidance is clear… it’s the system all the way from user interaction to data and back and all the abilities to deploy and install said product into production. In the large, forming a team like this isn’t usually possible, and often if possible, not advisable.

In the large, a product is actually a sub-system of a larger systems integration.

When you look at a product this way, it is often very possible to create a small cross-functional group of people that has everything, and everyone, necessary to produce a working, tested increment of product.

The idea is that you organize around products or features where you can, and you organize around subsystems where you have shared functionality. We call these collectively business capabilities. Once you have the business capabilities understood, you align the business capabilities with the technical architecture and ultimately the organizational architecture.

The intersection and alignment of business architecture, technical architecture, and organizational architecture is where you form a complete cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of their part of the product.

Because your business architecture, technical architecture, and organizational architecture are probably broken, you are going to have dependencies between these teams that are going to have to be managed. For now.

Over time, the job of the transformation initiative is to break these dependencies.

Dependencies are evil and they need to be broken.

The more you manage dependencies the less agile you will be, period.

Over time, as you break these dependencies, you will be able to treat each of these teams as pure play agile teams.

Until you start forming teams that align business capabilities with technical architecture and organizational architecture, and begin the hard work of breaking dependencies… all you can do is go through the motions of Scrum. You will never get the value you are working towards.

I’m telling you guys… the reason you’re doing agile and not feeling very agile is because you don’t have these kinds of teams and you have way too many dependencies.

No amount of daily standup meetings is going to fix this problem.

An agile culture won’t do the hard work for you.

The post What Is An Agile Team and How Do You Form Them? appeared first on LeadingAgile.

Categories: Blogs

Ten Outsourcing Considerations

Bobtuse Bobservations - Bob MacNeal - Fri, 02/27/2015 - 04:07
Software developer testing with JUnitTen outsourcing considerations when choosing a software development team: Are they local?Are they recommended by someone you trust?Are they demonstrably...

Bobtuse can be wildly informative
Categories: Blogs

The One Immutable Law of Adopting Agile

Leading Agile - Thu, 02/26/2015 - 10:00

I have three non-negotiables when it comes to running an agile transformation. If we are unwilling to create clear, well-articulated backlogs… if we are unwilling to form complete cross-functional teams… and if we are unwilling to produce working, tested software on regular intervals… we probably shouldn’t even get started. Without these three pre-conditions it is unlikely that adopting agile practices (or even an agile culture) will make much of a dent in terms of how you put product into market.

That said, the number one thing that gets in the way of creating clear, well-artciulated backlogs, forming complete cross-functional teams, and producing working tested software on regular intervals is dependencies. Let’s just say it… dependencies are evil. Dependencies break agile. You have two choices when faced with a dependency… you can either break it or you can manage it. The more dependencies you choose to manage instead of breaking, the less agile you will be over time.

This might just be the one immutable law of adopting agile.

The post The One Immutable Law of Adopting Agile appeared first on LeadingAgile.

Categories: Blogs

ScrumDay France, Paris, April 2-3 2015

Scrum Expert - Thu, 02/26/2015 - 09:31
ScrumDay France is a two-day conference taking place in Paris. It is focused on all aspects of Scrum with session in French but with keynotes in English. In the agenda of the ScrumDay France you can find topics like “Simple but not simplistic” avec Dave Snowden, “The Scaling Dilemma” by Mary Poppendieck, “Équipes agiles : survivre à la disparition des managers”, “Dérapage contrôlé en toute agilité!”, “Les équipes Produit à l’assaut des silos!”, “Migrez vers le Management 3.0″, “Scrum Shu Ha Ri”, . Web site: http://www.scrumday.fr/ Location for the ScrumDay France conference: Disneyland ...
Categories: Communities

Why LeadingAgile?

Leading Agile - Thu, 02/26/2015 - 03:47

We are working on more video for the site to tell our story. This is the first stab.

The post Why LeadingAgile? appeared first on LeadingAgile.

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.