Skip to content

Feed aggregator

MVF, MMF, WTF

TargetProcess - Edge of Chaos Blog - 3 hours 19 min ago

The concept of Minimal Viable Feature (MVF) is a significant milestone in product development. Release something that you think solve a problem and listen for the feedback. While the concept itself is great, the devil is in the details. In general, it is quite hard to learn how to define MVF. It is an art, not a science. In this article I will share my experience and some patterns I learned.

#1 Cut. The. Scope.

The most common mistake in MVF definition is bloated scope. There is always a desire to put one more thing into the feature and make it more useful and more appealing to the end user. No Product Owner can resist this intention and in almost every single feature I lead I added some unplanned user stories. In fact there is nothing bad with this approach, you discover new information and change plans. However, there is a real danger to push feature beyond MVF and delay its release. 9 months feature? We had it in our company.

Now we have a 3-months rule for every MVF. There should be serious reasons to spend more than 3 months on MVF implementation. MVF goal is to prove concepts and discover “unknowns”, don’t blow it to MMF.

#2 Feature kick start

Everybody should understand why we add this feature into a product. There is only one reason to add a new feature — it solves some important problem that quite many users face quite often. In the simplest case you have hundreds of requests that picture problem in bright colors and all you have to do is invent a solution. In a more complex case users don’t fully understand the problem and throw out various solutions that in fact don’t solve this particular problem. Only experience and system-level thinking can help to spot such cases. In the worst case you have no feedback and rely on your intuition to define the problem. This is a dangerous practice that can lead to extreme results: genius insights or total fuck-ups.

On a Feature Kick Start meetings we have people from marketing, development, testing, design and sales. All bring valuable information about various facets of the problem.

Product Board Meeting

These meetings have several goals:

  1. Clearly define the problem we solve.
  2. Define a scope of MVF.
  3. Decide what we don’t know and what feedback we will accumulate now and after MVF release.
  4. Bring development team and sales people to a common understanding about the feature.
#3 Huge upfront UX is bad

We tend to have UX and Development as a completely separate activities. Sometimes we spent months on a feature UX, built prototypes, tested them and then boom… priorities changed and feature is no longer needed so much. Almost all the time we spent was just a waste. Let’s say we get back to the feature next year, but now we have new information and UX we did a year ago is obsolete now, so we have to start over again.

UX and Development phases

Now we start UX when feature is actually starts. It means Feature Team almost completed previous feature, so it has some spare time to dig into the new feature and discuss its design, flows, etc. It may happen that developers don’t do much for some time, since UX is not ready. However, there are often many things they can do: fix some old bugs in background, prototype new feature, try some technical and architectural ideas, implement something we 100% certain about. So while in theory it looks like you are not “utilising 100% of resources capacity”, in practice single-feature flow for a Feature Team shortens cycle time and reduced waste activities.

#4 MMF is inevitable

Usually MVF solves a part of a problem and some cases are missing. Usually the solution itself is not the best. In most cases MVF is not a “complete” feature and you should finalize it. We call this finalization Minimal Marketable Feature (MMF). At this point feature provides a complete solution to a problem, the solution itself is beautifully designed, it is on par or outperform similar solutions in competitive products.

MVF and MMF flows

It may happen that new feedback will reveal that MMF is still not enough, so then you can iterate and release as many improved features as you need. This process is not formalized in our company.

#5 Real feedback is slow

We hoped to have 2-3 weeks delay between MVF and MMF and we thought it will be enough to accumulate enough feedback. We wanted to have process like that:

MVF - MMF - MVF - MMF

However, in most cases it takes 2-4 months to generate good amount of relevant feedback. It takes time to accumulate and reveal common patterns. For example, we re-designed navigation and allowed users to create their own Groups and Views inside these Groups (BTW, it was the case when we throw out UX done 9 months before feature start). It took us 5 months to actually understand what mistakes were made and what problems most companies have with this new flexible navigation. It appeared, the navigation was too flexible, so now we are reducing this flexibility and add some restrictions.

We changed the process and now we plan for 3 months delay between MVF and MMF. This gap is used by another MVF, so on a high level we release first minimal feature, that release second minimal feature and then based on generated feedback we complete both features.

MVF  - MVF - MMF - MMF

#6 Real feedback comes from real usage

Don’t get me wrong, I’m not against prototypes, wireframes sharing, surveys, etc. However, my experience showed that the only way to get a really relevant feedback is to release something in a product. All other ways of feedback generation are flawed. Real users bring so many unexpected and interesting insights.

When we started UX process adoption on our company 6 years ago, we tried almost any possible way of feedback gathering. We created several solutions to a single problem and run usability tests, ran surveys, interviewed customers, ran UX groups and shared concepts and ideas. We still use most of the methods from time to time, but our current approach is extremely lightweight and balanced. In general, we build light prototypes only when we just can’t select a solution from two options (50/50 votes inside our team). We never build full interactive prototypes that replicates future system behavior, but just share sketches and main concepts. With right questions asked this simple method allow us to get a very nice preliminary feedback.

TL;DR
  1. Set clear MVF goal and cut MVF scope that beyond this goal.
  2. Bring sales, marketing, development and design people together to define MVF.
  3. Huge UX phase upfront is bad and usually leads to waste.
  4. MVF is not a full feature. Embrace it and don’t rush.
  5. Real feedback comes from a delivered feature only.
  6. It takes several months to accumulate information to reveal patterns and decide how to improve feature.
Categories: Companies

Thinking About #NoEstimates?

Johanna Rothman - Fri, 04/24/2015 - 13:32

I have a new article up on agileconnection.com called The Case for #NoEstimates.

The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have time to compose thoughtful replies!

This column is the follow-on to How Do Your Estimates Provide Value?

If you would like to learn to estimate better or recover from “incorrect” estimates (an oxymoron if I ever heard one), see Predicting the Unpredictable. (All estimates are guesses. If they are ever correct, it’s because we got lucky.)

Categories: Blogs

The Need for Continuous Improvement in Agile

Ben Linders - Fri, 04/24/2015 - 02:50
Yesterday I gave a well received keynote at the QCon Beijing conference, in which I explained why continuous improvement is essential to deliver value with agile. QCon Beijing was the largest QCon conference so far with over 1600 attendants. Continue reading →
Categories: Blogs

BREAKING NEWS: Women’s Restroom – SECRETS REVEALED!

About SCRUM - Hamid Shojaee Axosoft - Thu, 04/23/2015 - 22:26

women's sign

Since the dawn of time, inquiring minds have wanted to know… “What really happens in the Women’s Restroom?! Why do they go in twos? Are they crying? Gossiping? Pillow fighting? WTF?!

Answers have remained a mystery… until now. Turns out, this seemingly innocuous space has one very big secret! Axosoft has used their agile powers to infiltrate the system and break the bathroom code once and for all! The most shocking part… It was right in front of our faces this whole time! That’s right, the passive woman plastered on the outside of bathrooms around the world, the one wearing a triangle dress, has been holding in something bigger than pee pee (and we’re not talking #2)! The secret she holds every single day will be revealed at the Girls in Tech Catalyst Conference and all we can say is… It was never a dress!

Categories: Companies

Agile France, Paris, France, June 18-19 2015

Scrum Expert - Thu, 04/23/2015 - 18:00
Agile France is a two-day conference focused on Agile and Scrum that takes place in Paris. It presents Agile practices, discusses their limitations and explore new approaches. All the presentations are in French. In the agenda of the Agile France conference you can find topics like ” Story Map, Story Map, Story Map … Comment on fait ?”, “Let’s sketch together !”, “Manipulé à l’insu de mon plein gré”, “User Stories, what else ?” or “From Legacy Code to Legacy Tests”. Web site: http://conference-agile.fr/ Location for the Agile France conference: Chalet de la ...
Categories: Communities

What Is The Goal?

Leading Agile - Thu, 04/23/2015 - 15:03

What is the goal?

I seem to lead with that question a lot these days. Is the goal to practice Scrum? Is the goal to apply SAFe? Is the goal to use some other Agile delivery framework? Is the goal to uphold the values and principles of the Agile Manifesto?

They are all means to an end. Your goal depends on your organization. Fundamentally, every for-profit organization I’ve come in contact with has pretty much the same primary goal. Make money!

Before committing budget for that next project, let’s first ask ourselves if we know our core business drivers.

Common Business Drivers
  • Predictability
  • Higher Quality
  • Shorter time to market
  • Lower Costs

But let’s look at this again. What is the primary goal? Make money!

How do we achieve the goal?
  • Through predictability, we get better at forecasting sales and delivery (lead times)
  • Through higher quality, we lower costs of rework and increase customer satisfaction
  • With shorter time to market, we can get an earlier ROI and increase cash flow
  • With lower costs, we free up capital for other areas of our organization
Answer these questions:
  1. What is your primary organizational goal?
  2. What are your core business drivers, relative to your primary organizational goal?
  3. If you don’t know the goal, how do you know where to spend your time or money?
  4. How do you know where to start?

The post What Is The Goal? appeared first on LeadingAgile.

Categories: Blogs

ESP compared to Kanban Method

David J. Anderson & Associates - Thu, 04/23/2015 - 12:58

I've been giving some careful thought to why it became necessary to create the concept of Enterprise Services Planning.

At the most fundamental level, ESP was necessary to provide a container for the collection of things we were teaching that were beyond kanban systems and beyond the scope of the Kanban Method. These were the things that enabled the optimal and effective use of kanban systems - topics such as: probabilistic forecasting and statistical analysis; qualitative risk assessment; real option theory; connecting strategy to operational mechanisms such as Kanban capacity allocation; and so forth. ESP represents a system of management for an entire professional services business. It isn't just an IT thing and it certainly isn't just for operational management of a single service delivery workflow. So we needed a name that encompassed concepts that were a lot bigger than Kanban.

read more

Categories: Companies

Kanban Cadences

David J. Anderson & Associates - Thu, 04/23/2015 - 12:14

Recently, I've taken a new approach to teaching The Kanban Method. The new Lean Kanban "Practicing the Kanban Method" class is built around the 7 Kanban Cadences - the cyclical meetings that drive evolutionary change and "fit for purpose" service delivery. Two of these meetings are relatively new additions to the method: Risk Review added in 2014 as a response to Klaus Leopold formalizing Blocker Clustering in 2013; and Strategy Review as an emergent response to the concept of "fit for purpose" and the need to sense the external environment, in order to be able to respond appropriately. The other 5 were existing elements of the method, though the first edition of my Kanban book ommitted Service Delivery Review. In truth our training has not until now emphasized these meetings and particularly replenishment/commitment and delivery planning have not been explicitly taught. Little wonder then that these very basic functions of Kanban have not been well implemented in the field.

read more

Categories: Companies

12 Failure Modes of an Agile Transformation

Rally Agile Blog - Wed, 04/22/2015 - 21:15

The year? 2015. The setting? An Agile transformation near you. The problem? You’ve hit a wall. Despite all your best intentions, you’re still not getting those promised benefits of Agile: speed, quality, value, sustainable growth across your organization. And your problems don’t stop there. You aren’t responding to market threats; you can’t even see market threats; you’re unable to retain great employees; you’re not an industry showcase. In the end, your Agile transformation has brought cynicism and distrust.

You may have heard me talk about “12 Agile Adoption Failure Modes” that concentrated on agile failure in the context of IT teams. Given the expanded adoption of Agile practices in organizations beyond the IT group, the threat of failure is now farther-reaching, with bigger impact.

Now it’s imperative that we look not just at Agile adoption, but at Agile transformation — where organizations move beyond Agile principles within their IT groups to business agility. To accomplish this, we transform from just doing Agile to being Agile.

Over the next few weeks I’ll share with you the top 12 failure modes of an Agile transformation that I’m witnessing in my work with organizations around the globe. Following are the first three.

1. Lack of Executive Sponsorship

This failure mode evidences itself in several different ways and ultimately, it warrants its spot as the number one failure mode and drives all the other failure modes. Also known as “buzzword buy-in,” a lack of executive sponsorship can come at you from two directions

Imagine a small group of techies eager to adopt Agile in their team. With no executive sponsorship, they perform in a stealth environment — sort of a “skunkworks” adoption — under the radar of the existing organizational structure. Why? Because they’re hiding from the hierarchy of management (see the second failure mode, below) which could shut down their effort, and evading the current gate-driven approach to product delivery. While the project may gain some momentum, deliver value faster, and stir the souls of those involved, its sustainability is improbable. Lack of executive sponsorship will limit visibility into the team’s success and provide insufficient support for adoption across subsequent teams. Agile adopted this way will likely die.

In our second scenario, an executive decrees a switch to Agile delivery across the entire IT organization, but there’s no real follow-through: it’s simply a “checkbook commitment.” The executive demands immediate results, yet doesn’t change the metrics by which success is measured. Unengaged, the executive proclamation for an Agile adoption will never move to a true business transformation. At best, without the executive’s continued engagement, the organization will only have pockets of Agile success, typically limited to the team level. The organization will probably grow to blame Agile (and each other) for decreased quality and productivity. And the executive’s resignation letter will conveniently not include the word “Agile” in its summary of successes.

How do we prevent this failure? Leaders must accept that a successful transformation is a journey. Along this journey, leaders seek guidance for a transformation with a broad, sustainable impact. As part of the transformation they make a personal commitment to their teams, and in turn they recognize the personal commitment they are asking of their employees. Executives commit to measuring success differently from before, because the work is different from before. Success now favors value delivery, and time for learning is built into the transformation. Ultimately, success is celebrated across the organization and setbacks are seen not as failures or cause for blame, but as opportunities for learning and growth.

2. Failure to Transform Leader Behaviors

Isn’t it great to have managers who just get things done? They know the right actions to achieve success; they direct their teams to perform these actions; and they have the power to control all aspects of the work and do whatever it takes to get it done.

Huh?

Let’s pull this apart a little. When a manager tells the team what to do, there’s a false sense of success via control. When a manager powers through difficult circumstances regardless of the impact on the team, they leave the wisdom and the morale of the team behind.

Such a management style is a classic Agile transformation failure mode. All the team-level Agile practices in the world mean nothing if the manager doesn’t embrace a behavior that is more in service to the team than control of the team. Robert Greenleaf’s work identifies the characteristics of what he calls a “servant leader”: one who serves by leading, and leads by serving. An Agile transformation success story hinges on the ability of the leaders in the organization to take on these characteristics:

  • Systematic neglect: knows the limits of how much focus can be allocated to issues; learns what to focus on and what to let go of in order to support the team and achieve goals effectively

  • Acceptance: knows when to let go and trust the instincts of the team; accepts the wisdom of the team and is prepared to support it

  • Listening: facilitates useful and necessary communication, pays attention to what remains unspoken, and is motivated to actively hear what others are saying

  • Language: speaks effectively and non-destructively; clearly and consistently articulates the vision and goals for the team

  • Values: is responsible for building a personal sense of values that are clearly exhibited through consistent actions; supports team behaviors that build their sense of values

  • Tolerance of imperfection: modulates his or her own sense of perfection and offers to each team member an understanding of their strengths and challenges; cares more about “How can I help the team grow?”

  • Goal setting: owns the vision; doesn’t advocate for a personal belief in what is right but rather maintains the goal for a higher purpose, inviting others to align with the vision for the overall good

  • Personal growth: recognizes the value of continually finding diverse disciplines that invite new ways of acting in service to the team, and models this growth behavior to inspire others

  • Withdrawal: knows when to step back and allow the team to figure out its course, versus inflicting a personal sense of what is right for the team; carefully decides what to bring forward and when

3. No Change to the Organizational Infrastructure

What is your current organizational structure? How many layers of management exist around each Agile team? How is governance perceived, and who is ready to break down walls to make sure that value flows through your organization?

Failed Agile transformations suffer from an inability to change the existing organizational structure. What do I mean by this? Typical organizations have been set up for sub-optimization: that is, they measure success by departmental performance, versus overall value delivery. Here’s what that looks like: In the book This Is Lean, authors Niklas Modig and Par Ahlstrom depict a soccer field scattered with teams, each one in its own tent. Success is defined as any one team getting the ball out of its tent. But is that really success overall? In this scenario, as in our traditional organizations, we create accidental adversaries. We limit visibility of the organization’s overall effectiveness, and focus on our team’s success at the expense of success for the organization.  

True Agile transformations push the boundaries of these existing organizational hierarchies. In the soccer field metaphor, we remove the tents. Now everyone can see where the ball is, where everyone else is, where the goal is positioned, what the referee is indicating, what the coach is saying, and what the scoreboard says. In your effective Agile transformation, you know what the true value is, you know who needs to be involved in order for the value to be delivered, and everyone associated with the value delivery has visibility into the current state of the value stream, including its blocks. They see the goal as successful delivery of value to the customer, and they coordinate as a whole to deliver that value.

Here’s another symptom that your organizational infrastructure is crippling your Agile transformation: Does your organization cling to a notion of efficiency based on resource usage — believing that loading people to 100% capacity is the best way to get work done, and then measuring people annually by how well they deliver in this fully-loaded mode?

To incent greater collaboration and communication, you need to revisit how you appraise work. Instead of annually, by individual, 100% utilized, with MBOs set 12 months earlier, you should invite frequent feedback; focus more on team effectiveness; and bias performance appraisal toward efficiency of value flow versus efficiency of workers.

If you’re not feeling the discomfort change brings, you aren’t truly transforming. If your transformation isn’t requiring you to invest in the technology and culture to support a new mode of visibility and collaboration, you aren’t truly transforming. If you’re adopting some Agile practices at the project level without looking at the bigger picture, your Agile transformation is poised for failure. And Agile, not the failure to transform the organization, will get the blame.


Stay tuned to the blog for Jean’s next three Agile transformation failure modes.

Jean Tabaka
Categories: Companies

How I prioritized the criteria to buy an apartment

AgileEspresso - Davide Noaro - Tue, 04/21/2015 - 22:06
“You need to choose because you cannot have everything for that price.” This remembered me the typical discussions I had with our Product Owner when I was working in a Scrum team. “Prioritization” was the answer. The Product Owner was used to discuss with us the requirements, giving priorities to maximize the return on investment. […]
Categories: Blogs

11 Tips for a Successful Scrum Implementation

Mike Vizdos - Implementing Scrum - Tue, 04/21/2015 - 21:27
www.implementingscrum.com -- Cartoon -- April 21, 2008 Congratulations.

You may have just returned from an internal meeting where you were given some new orders to “go agile” with your team or group.

You may be responsible for leading an agency (or a professional services team) within your organization to “go agile.”

Your team is responsible to #deliver “using agile” or “using scrum” (This last posting may also help — “Holy CRAP I have to do THIS???”)

Now.  The pressure is on for you to do this TODAY.

Actually, YESTERDAY.

Your boss — or some other stakeholder — is demanding results.  Lucky you!

Do you feel a bit out of control or caught between a rock and a hard place?

Are you STUCK?

Here’s the secret:

You CAN enable the team to run in an agile manner using Scrum (or something like it).

How?

It’s pretty easy actually.  In real life, “easy” is anything BUT that (you know there is no Silver Bullet).

Let me help you. Let’s talk.

Or.

Here are TEN FREE STEPS to start on your own:

STEP ZERO:

I have this sinking feeling you may want to do this with all your teams and clients across the organization.  You want to jump in and scale this agile stuff in a big way and just GO FOR IT.

Don’t.

This is not time for you to panic.  This is not the time for you to make a career-limiting-move.

Here is what you can do.

STEP ONE:

Identify your most important (valuable?) client today.

Think about the pareto principle (80/20 rule).

You DO have those very valuable 20% of customers who DO provide you with 80% of your success.

Focus on them and use Scrum to #deliver with them.

Actually. Start with just ONE client (or customer).

Yes.  This means you will have to say NO to a lot of people.

It’s OK.

Remember that 80% of your current clients are keeping you up at night on wasteful non-value-added crap.  You may piss them off by saying NO; however, they are probably already pissed off at you and the cost of switching is either too high or they do not really feel enough pain and love blaming someone anyway.

They are not your problem. If you are bleeding now, this is not the time to keep doing whatever it was that you were doing in the past.

STEP TWO:

Have a real face-to-face conversation with your customer (or client) about playing the role of “Product Owner” for the ONE Scrum Team.

This is a HUGE commitment.  Amazing things happen when you ask.  I’ve seen it done and have helped others do this.  What seems unreasonable today really can happen when you Focus and #deliver together.

STEP THREE:

Now.

Dedicate a team of 5-9 people that can #deliver with your Product Owner on this Scrum Team.

Identify someone to play to role of the ScrumMaster; this person should have real world experience and failures someone else has paid them to make!

And.

Watch the magic happen.

STEP FOUR:

Create an initial Product Backlog together as a Scrum Team.  This should be based on the highest value project with a clear vision of the WHY effectively communicated by the Product Owner.

Don’t worry about estimating at this point.  Read up on the topic of #noEstimates and learn to Focus and #deliver together… as a real team.

STEP FIVE:

The Product Owner can prioritize the Product Backlog items however they feel is necessary.  Use Story Boarding or other ways to tease out the REAL value to your end users.  Oh… and do this quickly (think hours or two days MAX because there is no such thing as a “Sprint Zero”).

STEP SIX:

The Scrum Team can then plan their first Sprint using the Scrum Master as the facilitator.  The Development Team can figure out what to commit to (or forecast) for this Sprint (or Iteration).

Here’s the thing… they will be wrong.  It’s OK.  Focus and #deliver SOMETHING. The weather forecast is rarely right in the real world… but we learn to adjust real life to the real weather conditions as we learn more together.

STEP SEVEN:

Have a daily stand-up meeting each day for a short iteration (how about one week to get started!?!?!).

Allow for the team to coordinate on the Sprint Goal and meeting the Definition of Done for the Sprint.

STEP EIGHT:

Do the work. Daily.  This is where the miracles can happen and will evolve over time as your dedicated team becomes high performing [did I mention this will take time]?

STEP NINE:

At the end of the Sprint, host a Sprint Review.  Demo your Potentially Shippable Software — or Product Increment — together as a Scrum Team.  Have your Product Owner stand up and proudly show what the team was able to actually #deliver.

Gather feedback from your key stakeholders, project sponsors, and perhaps even you real world customers (or end users!).

Focus. #deliver

STEP TEN:

Gather your team for a Sprint Retrospective.

Learn together about what can improved in the next Sprint.

STEP ELEVEN:

Keep going.

That’s it.

Focus. #deliver

Need help?

LET’S TALK

 

 

WARNING The proverbial shit will probably hit the fan. Bad things WILL happen. This is totally normal.

As time takes time, the team DOES #deliver something.

Remember: Delivering the wrong thing TODAY is better than delivering the wrong thing months — or years — from now.

Focus.  #deliver

And.

Keep learning.

This is all good.

Easy.

Right?

I can help.

LET’S TALK

Categories: Blogs

Scrum Alliance Launches Learning Consortium

Scrum Expert - Tue, 04/21/2015 - 18:38
The Scrum Alliance has announced the formation of a Learning Consortium for the Creative Economy. The Learning Consortium comprises a diverse group of organizations in different sectors around the world that are exploring management innovation in the emerging Creative Economy. Learning Consortium organizations include agile42, Autodesk, Brillio, C.H. Robinson International, Ericsson, hhpberlin, Magna International, Menlo Innovations, Microsoft, PENSCO Trust, SolutionsIQ, and SWIFT. The Learning Consortium will explore the leadership and management practices emerging to deal with a marketplace that requires continuous customer-driven innovation. The Consortium will study ongoing transformational shifts ...
Categories: Communities

Crossing the Agile-UX Divide

Scrum Expert - Tue, 04/21/2015 - 17:28
Integrating UX into an Agile process is not always an easy challenge. In this article, Mike Bulajewski reminds the why the differences between the two vision exist in the first place and proposes some solutions on how they could be solved. This article provides a very interesting point of view of the Agile-UX relationship from the UX side. The article starts by reminding the origin of the Agile movement and how it changes the vision from the traditional software development. He thinks that for many agilists, “he mere existence of designers ...
Categories: Communities

No Matter What Your Strategy, You’d Better Deliver Fast!

Rally Agile Blog - Tue, 04/21/2015 - 17:00

Last month, Forrester released a wave of portfolio management industry reports. In the Portfolio Management for Tech Management wave, Rally was named among the ten most significant portfolio management software providers, and was the only Agile vendor featured in the report. The inclusion of a pure Agile vendor reflects the growing importance of executing portfolio plans faster to hit critical market windows.

In midsize to large organizations, delivering business value faster requires scaling Agile practices to coordinate a large number of teams to deliver on an entire portfolio scope. But a good strategy is irrelevant if you can’t deliver on it in the timeframe required to stay competitive. As companies realize this, faster portfolio execution becomes an imperative.

At the same time, many of these companies still have traditional financial controls that impede their ability to respond to market changes: project funding that locks in requirements for long periods of time and mandates that developers leave their environments to fill out timesheets — a process that often results in inaccurate cost reporting.

Changing those financial practices takes time — and you can’t afford to wait. If you work in one of those organizations, you can still scale your Agile practices to deliver faster by integrating the Rally platform with PPM vendors.

Planview — one of the leading PPM vendors — has been honing its integration with the Rally platform for several years to create a realtime connection between traditional portfolio planning and Agile portfolio execution. The latest Rally-Planview integration provides added granularity into the visibility of Agile projects from PPM dashboards. When adopting Agile, the more visibility you can give to business leaders, the faster they can adapt their plans to respond to changes.

The Forrester report recognized Rally for its software integrations with several PPM vendors. To learn how you can accelerate your portfolio execution, take our portfolio management tour.

Catherine Connor
Categories: Companies

Thinking About Estimation

Johanna Rothman - Tue, 04/21/2015 - 16:06

I have an article up on agileconnection.com. It’s called How Do Your Estimates Provide Value?

I’ve said before that We Need Planning; Do We Need Estimation? Sometimes we need estimates. Sometimes we don’t. That’s why I wrote Predicting the Unpredictable: Pragmatic Approaches for Estimating Cost or Schedule.

I’m not judging your estimates. I want you to consider how you use estimates.

BTW, if you have an article you would like to write for agileconnection.com, email it to me. I would love to provide you a place for your agile writing.

Categories: Blogs

ScrumMaster – Full Time or Not?

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I’ve been in some debates recently about whether the ScrumMaster should be full time. Many of the debates have been frustrating because they devolved into whether a team was better off with a full-time ScrumMaster or not.

I’ll be very clear on the issue: Of course, absolutely, positively, no doubt about it a team is better off with a full-time ScrumMaster.

But, a team is also better off with a full-time, 100 percent dedicated barista. Yes, that’s right: Your team would be more productive, quality would be higher, and you’d have more satisfied customers, if you had a full-time barista on your team.

What would a full-time barista do? Most of the time, the barista would probably just sit there waiting for someone to need coffee. But whenever someone was thirsty or under-caffeinated, the barista could spring into action.

The barista could probably track metrics to predict what time of day team members were most likely to want drinks, and have their drinks prepared for them in advance.

Is all this economically justified? I doubt it. But I am 100 percent sure a team would be more productive if they didn’t have to pour their own coffee. Is a team more productive when it has a fulltime ScrumMaster? Absolutely. Is it always economically justified? No.

What I found baffling while debating this issue was that teams who could not justify a full-time ScrumMaster were not really being left a viable Scrum option. Those taking the “100 percent or nothing” approach were saying that if you don’t have a dedicated ScrumMaster, don’t do Scrum. That’s wrong.

A dedicated ScrumMaster is great, but it is not economically justifiable in all cases. When it’s not, that should not rule out the use of Scrum.

And a note: I am not saying that one of the duties of the ScrumMaster is to fetch coffee for the team. It’s just an exaggeration of a role that would make any team more productive.

Categories: Blogs

February Dallas Recap: Discover the Power of Pair Testing

DFW Scrum User Group - Tue, 04/21/2015 - 15:28
In February, we were fortunate to have DFW Scrummer Pradeepa Narayanaswamy present at our Dallas meeting. Agile teams are expected to deliver high quality product, and team members become more cross-functional and take ownership of quality. To address scarce testing … Continue reading →
Categories: Communities

The Next Most Important Thing

Leading Agile - Tue, 04/21/2015 - 14:16

Finding your next most important thing is critical and requires clarity. As teams begin thinking about how to address their meetings, the topic of a previous post, its critical that they first identify where the team needs to focus its energy over the next 1-3 months, or the “next most important thing” the team needs to do in order to succeed.

So, how would a team go about identifying their “next most important thing”… It’s a fairly straightforward process.

For the sake of a tangible example, I’d like to use a set of three types of teams that I work with on a regular basis, teams that operate within a three tier enterprise product development structure. These teams and their purpose would be defined as follows:

  • Product development team: Produce the next most important working increment of product within a couple of weeks.
  • Program team: Establish and provide clarity for and to product development teams about the next most important increments of product that are needed within the next few months.
  • Enterprise portfolio team: Establish and provide clarity for and to program teams about their next most important thing for the portfolio to succeed. This usually requires creating or maintaining a multi-quarter capacity-aligned roadmap for the products and services that are owned by the portfolio.

With these perspectives in mind here is the process that I would recommend for identifying the next most important thing within each team:

  1. Review the team’s primary purpose,
  2. Ask each team member to write down the one thing within its control that is keeping the team from fulfilling its primary purpose,
  3. Review the team’s suggestions and filter the list down to the one thing that the team agrees is the most important goal for the next period.

It’s important to recall that the next most important thing for a portfolio team may look very different from the next most important thing for a product development team.

So, how would a portfolio team member identify the portfolio’s next most important thing? I’d recommend that they answer this question:

What is keeping our portfolio from delivering the next most important increments of product into the markets within the next 3-9 months?

Likewise for a program team member I would recommend the following question:

What is keeping our program from providing clarity to the product development teams about the next most important increment of product?

And finally for a product development team I would recommend the following question be answered:

What is keeping our team from delivering a working increment of product within a couple of weeks?

In each of these cases, the next most important thing would be directly tied back to the primary purpose for the team and would be expected to be resolved within a short period. Once we know what the next most important thing for the team is, we can start to identify which types of meetings we will need and how frequently we will need them to ensure that we are accomplishing our next most important thing.

What do you think, are there other examples that you would like to hear more about or perhaps where you have seen this fail?

And as always, thanks for reading and sharing your feedback!

The post The Next Most Important Thing appeared first on LeadingAgile.

Categories: Blogs

Agile Day Riga, Riga, Latvia, May 23 2015

Scrum Expert - Tue, 04/21/2015 - 09:49
Agile Day Riga is a one-day conference focused on Agile project management and Scrum. Presentations and workshops will be in Latvian, English and Russian. In the agenda of Agile Day Riga you can find topics like “Being Agile to become Customer centric”, “Agile Innovation – Why people matters”, “Agile Metrics – what is really needed and makes sense in order to steer a large agile project “, “Is “your” Scrum working?” , “Software architecture also needs Agile”, “Why We Fail to Change”. Web site: http://agiledayriga.lv/ Location for the Agile Day Riga conference: Islande ...
Categories: Communities

Axosoft Partners with Girls in Tech

About SCRUM - Hamid Shojaee Axosoft - Mon, 04/20/2015 - 19:44

Here at Axosoft, we love our tech community, and we recognize the significant yet still underrepresented achievements and initiatives of women in the technology industry in AZ and abroad. As a tech company with a female CEO, we are not only active in supporting the tech community and championing the women at its forefront – we are actively seeking to expand our female workforce by adding more female developers to our team.

Axosoft-Woman-Screen_sm

What better way to find female developers than to help create them? Don’t worry, we don’t mean in a creepy futuristic cloning way. Axosoft has partnered with CodaKid, a Scottsdale-based kids computer programming and game design academy, to offer fun and free workshops and codeathons that teach girls how to code as early as age 6.

We are constantly trying to align ourselves with great partners like Girls in Tech and CodaKid who share our vision for growing STEM education and the tech industry. As prominent players in the Valley’s technology ecosystem for over a decade, we are honored to be the lead sponsor of the Girls in Tech Catalyst Conference!

The speakers at this event represent some of the very best technological innovators, thinkers, entrepreneurs, and leaders in the Valley. And, it just so happens they are women. These superheroes, alongside the attendees of the conference, showcase just how strong, energetic and productive a network of driven and influential women exists in Arizona. This conference shows off the amazing women doing things right now on our own turf, and in doing so represents similar innovations globally.

We are SUPER excited to partner with Girls in Tech in celebrating the vibrancy and diversity of this growing movement, sharing in their vision to empower women in the technology industry, spread knowledge and inspire more companies like ours to create the next big thing.

Categories: Companies

Scrum Knowledge Sharing

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