Page 4 of 7

MVP, MLP, MMF and the whole Bunch

August 21, 2017 / rrosendahl / 0 Comments

In the context of Lean Product Development, there are now a number of acronyms in circulation among Product Managers and Agilists and many of them are similar and seem to overlap. In essence, they are all rooted in the belief that it doesn’t make sense to launch and release complete, feature-rich products which take many months (or even years!) to develop without first obtaining market feedback to validate that one has a good understanding of the problem to be solved and a viable solution for it.

Here is how I personally make sense of the various 3-letter acronyms and related concepts (full disclosure: this is my thinking and may not fully mesh with the official definitions):

Experiments: When we put up experimental landing pages describing a product with means to “sign up” for more information etc, there is no product here, at best a description and/or depiction of a potential future product. While great for learning, I would not use any terms that include the word “product” because we really don’t have one yet. The same applies to mock-ups, prototypes, etc. Those make no product although these artifacts can be very useful learning devices. Experiments take place before an actual product exists.

MVP (Minimally Viable Product): This is a production-worthy actual product with the smallest feature set to make it useful for users and allow the company to obtain feedback from the market, which can then be used to further iterate on the product, including more significant pivots. The MVP has hopefully been validated by earlier experiments before being built. One catch: If we release what we think is an MVP and the market response is horrible and it crashes and burns (it doesn’t meet market needs and fails defined product success measurements), I would argue it wasn’t actually viable to begin with. While not always fun, a failing MVP is a good thing (remember “fail fast”?) because the early learnings will result in significant savings because we don’t end up developing the full product, just find out months later that it fails. The MVP is about validation and obtaining market feedback.

MLP (Minimally Lovable Product): Some found that certain MVPs were so minimalistic and spartan that they weren’t appealing to users. What was missing was the ability of users to form an emotional connection to the product. Hence people started using the term MLP to denote that the product must be enjoyable for the users. Then again, one could argue that maybe then the MVP as such wasn’t really viable since it was missing things to make the product compelling. The MLP emphasizes the emotional connection with the users.

MMF (Minimally Marketable Feature): The MMF is very close to the MVP (at least in my mind), except it focuses on marketing the product. Maybe this distinction is more significant in cases where the users of the product are not the same as the people who buy and pay for it. The MMF is about wether a product is sufficiently developed in terms of feature set to be marketed and sold.

So really, apart from early experiments, MVP, MLP and MMF are all very closely related; they just seem to each emphasize certain aspects more than others.

Product folks out there, does this resonate with you?

From ALM to GLM

February 2, 2017 / rrosendahl / 0 Comments

The Evolution of ALM Applications

ALM (Agile Lifecycle Management) solutions, i.e. applications that help Agile teams deliver software solutions, have come a long way. They started out as tools to manage a backlog and assist teams with working on stories and defects in sprints. Then came collaboration features, reporting and the ability to work in Kanban. As the number of teams grew and more complicated work had to be organized and managed, portfolio items/epics appeared which helped group related stories into higher level aggregates.

In recent years, the ALMs (such as VersionOne) increased their functional footprint into other adjacent areas:

PPM – project portfolio management: Higher level roll-ups, reporting, forecasting and even budget tracking were introduced in the attempt to meet the needs of leaders and manage portfolios of work..
Product planning and roadmapping – This area, which is still in the early stages of being conquered by ALMs, involves product strategy, ideation & planning, roadmapping, story mapping, etc., i.e. The part of the product life cycle before items are defined enough to be worked by Agile teams.
DevOps – The realization that fully tested software coming out of Agile teams by itself adds no value until it is deployed and running in production was catalyst for forays into DevOps and automation to accelerate and automate the “last mile” of the development process with the goal of increased visibility and ultimately continuous deployment.

While the ALMs aim to cover core functionality in these different areas and continue to push their boundaries, it is also common to offer integrations for more sophisticated solutions in these areas in case the ALM customers demand highly specialized functionality.

The Next Frontier: GLM

While ALMs do a good job of ushering work items through the Agile process and even carry it all the way to becoming deployed software in production, there is a different class of items that – often invisibly – work their way through Agile teams and organizations: growth and learning. As Agilists we know that our teams, programs and portfolios should constantly evolve and improve. We are inspecting and adapting and applying Kaizen on an ongoing basis to improve.

The “items” in this case are not stories, defects or even epics/portfolio items; they are improvements and learning objectives (I’ll refer to these as growth items). At the team level, growth items may result from retrospective meetings and sometimes manifest themselves as improvement stories (or issues) in the ALM’s sprint backlogs or on the wall in the team room. While growth items are fundamentally different than stories and defects, making them visible as part of the backlog ensures the team remains focused on dealing with them.

This approach at the team level works reasonably well, although growth items are a different class of items and often don’t follow the same rules and flow of regular backlog items. Example: these improvements are often not part of the sprint commitment because they may require more time to resolve. Including them as part of tasking and burn down may also not work overly well. Frequently, growth items also require experimentation and several rounds of inspection and adaption spanning multiple sprints before they can be considered resolved.

Today’s ALMs may offer some solutions for team-level growth items but often that functionality is more of an afterthought. Where the approach breaks down even more is when those growth items that are outside the teams’ control and need attention and resolution by higher level entities, which could be programs, portfolios, functional leaders and senior management (example: a company’s facilities do not provide sufficient space for teams to collocate and effective collaborate). (See also: Closing the Impediment Gap.)

The ALMs don’t currently provide functionality to effectively deal with organizational growth items and I would argue that similar to specialized solutions for other adjacent areas there is room here for a new class of solutions I’d like to call Growth Lifecycle Management (GLM) applications. With learning and improvements being at the core of healthy Agile/Lean enterprises, GLMs should provide the mechanisms to capture, communicate, aggregate, analyze growth items, manage their resolution and analyze their impact on an organization. The latter will ultimately require integration and sharing of data with traditional ALMs in order to facilitate the correlation of growth item resolution and team and organizational performance.

The Growth Item Value Loop

In the Agile world, many of us are familiar with the concept of value stream: items of value (stories, features, etc.) flow through a series of steps after which value is delivered to the organization, e.g. by users being able to utilize new functionality in production. The flow in this case is unidirectional (often depicted left to right) and in most cases all items make it through the stream beginning to end.

Growth items tend to behave differently: First of all, not all items make it through the various steps. More like a sales funnel, at each step items may be dropped or dismissed, which reduces to potential output of value and limits the number of items exiting the process compared to the number of items entering the process. Examples: teams end up not implementing improvements they identified or leaders only select 4 out 10 identified organizational growth items based on capacity or expected ROI.

Secondly, the process isn’t strictly unidirectional with a single entry and exit point. Growth and incremental improvements are based on feedback loops. At the team level, members experiment with things that may resolve impediments and inspect & adapt. At the leadership level, leaders resolving organization growth item provide feedback to the teams which positively affects the health and motivates the teams and creates a self-reinforcing loop.

Due to these differences compared to the commonly used concept of value stream, I propose the term “value loop”. Let’s look at the steps in detail:

Growth items get identified through Agile ceremonies such as sprint retrospectives or strategic retrospectives as suggested by AgilityHealth.
Growth items get collected in a growth backlog and prioritized.
Items that teams have the ability to address get worked on by Agile teams. Due to teams’ limited capacity only the highest value items may get worked on. Experimentation and inspect & adapt results in feedback loops and iteration over time.
Organizational growth items that teams themselves cannot resolve themselves require leadership to get involved. Leadership teams have to be formed consisting of at those leaders that have a stake in and ability to resolve those items.
Once formed, growth leadership teams work on addressing the highest value items since these teams too are often constraint in their capacity. When they are able to resolve items, feedback should be provided to the teams that identified the growth items, so that teams see that their voices are heard and that leadership takes them seriously and is interested in enabling them go get better and healthier. This type of feedback will reinforce the value of this process.
Out of all items on the growth backlog, the most pressing items will hopefully see resolution by teams and leadership.
The immediate impact of resolved growth items is improved team health, which has various components including morale/happiness, effectiveness, level of collaboration, and skills.
Improved team health will result in improved team performance which manifests itself in higher quality, throughput, value delivered or customer satisfaction which should tangibly benefit the organization and its financial performance.

I used the term “value loop” since the overall process is iterative and continuous as opposed to linear in nature. Improvements never stop and feed on each other as also suggested by “Kaizen”.

What’s the relationship between the Growth Item Value Loop and the regular value streams? The Growth Item Value Loop lives inside the value stream. As it spins and picks up speed, it can act as an accelerator to the overall value stream as the improvements in health and performance positively affects the overall value stream performance. This dynamic also makes a compelling business case for focusing energy on the Growth Item Value Loop.

In Summary: The growth item lifecycle is very different than the lifecycle of traditional work items going through their value stream. Despite various vectors of functional growth, current ALM solutions do not effectively encapsulate the Growth Item Value Loop. Since this loop is at the core of Lean/Agile and valuable accelerant with tangible business impacts, there is room for application providers to cover this still relatively uncharted territory of GLM.

Views of Organizations – Mechanistic or Humanistic?

November 18, 2016 / rrosendahl / 0 Comments

During conversations with various individuals about Agile organizations, I realized that, more often than not, there are two main ways they seem to think about them:

The Mechanistic View

org-chart When people take a mechanistic view of an organization, they believe it can successfully and exhaustively be described through its structure and processes. There are clear inputs and outputs that can and should be measured (and shown on dashboards). Clear correlations and relationships exist and metrics are driven through use of known “levers”. Order is created by following consistent processes and best practices. The people that make up these organizations are “resources” and certainly play an important role, but at end of the day it’s about hiring, training, retaining and measuring engagement. This world has clear rules and could be described by a good deterministic model with underlying predictable formulas and mechanisms. At its foundation, this view of organizations is rooted in Taylorism and management principles from the industrial revolution.

The Humanistic View

cas On the other side of the spectrum, we find individuals thinking of an organization in humanistic terms. Organizations are organic and the sum of the individuals and teams they are made up of. These “cells” form an organism that often doesn’t follow predictable rules but functions through complex interactions and relationships that often escape the attempt of description via simple mathematical models. While org charts and processes do exist, the humanistic view accepts that these are solely simplistic attempts at describing how such an organization really works. This thinking is more in line with the theory of complex adaptive systems. Complex human beings are the building blocks of these organizations who deserve to be motivated and communicated to, their potential should be unlocked and they should be allowed to organize around problems and solve them. Instead of processes, we find emphasis on culture, values and principles. At its core, this point of view evolved from more recent research and thinking about how organizations, which are nowadays occupied predominantly by knowledge workers, function.

Which of these views is “right”? As Agilists we certainly gravitate more towards the humanistic view. Nonetheless, both views are valid and valuable models describing organizations knowing that a model is itself defined as a (over-) simplified representation of an entity, so it can never be fully accurate. At the end of the day, both these views can prove useful given the right circumstances as long as we deliberately choose which one to use and understand its potential shortcomings. I do believe, though, that the humanistic view pays better tribute to the complexity of today’s world. What gets us in trouble is when, based on traditional management training, we are hard-wired to only take the mechanistic view without being able to acknowledge the complex inner workings of today’s businesses and that in the end we need to trust and rely on people to make our organizations successful.

It’s about Time

August 16, 2016 / rrosendahl / 0 Comments

As Agilist and developer, I recently created a Mac OS app to help with timeboxing Agile ceremonies, workshops, Lean Coffee events, etc. Check it out – maybe you’ll find it useful!

Agile Debt

August 13, 2016 / rrosendahl / 0 Comments

Many companies are very much aware of what is called “technical debt”. While there are several trains of thought and definitions around this term, I’d explain technical debt– for the purposes of this conversation – as known technical shortcuts or compromises that were taken in the course of developing something or known, non-critical defects that are allowed to exist, at least for some period of time. Examples: Developers choose a sub-optimal technical design of a solution that is known to be less robust, but quicker to implement. Or: a key feature in need of being released to the market still has several medium-severity bugs that are deemed non-critical, so the feature is released with those defects. In either case, technical debt is like regular debt in that it has to be paid off, hopefully sooner than later, by refactoring the code, rectifying the design/architecture or fixing those known bugs. If not attended to, technical debt will pile up and make the product unreliable, fragile and harder to maintain in future. Some would argue that unresolved technical debt over time even incurs something equivalent to interest in that it gets – like financial debt – harder and harder to resolve. Mounting technical debt is also known to slow down new feature development as more and more energy is spent on just keeping technical issues under control.

Back to Agile: is there something equivalent to technical debt when it comes to transforming teams and an organization and moving them to Agile? I would argue yes, there is. Let’s think about some examples.

Focus on practices without anchoring on values and addressing culture
Ignoring of traditional behavioral patterns and management styles.
Reliance on external consultants without growing local roots.
Team-only approach without addressing team context and organizational impediments.
Insufficient training (team members, Scrum Masters and Product Owners).
Not investing in internal coaching and sustainment after the initial transformation (see Keeping the Agile Ship on Course).
Leading the transformation with the implementation of an Agile tool (ALM) and assuming this will make teams Agile.
Grass-roots only, bottom-up transformations without leadership support.

These are just a few examples that come to mind. To see other common anti-patterns, I recommend looking at the results of VersionOne’s annual State of Agile Survey.

The shortcuts mentioned above will – by themselves – not automatically result in doom and complete failure of an Agile transformation. However, similar to technical debt, they will weaken the impact and progress of a comprehensive transformation and limit the benefits the organization will reap. Dealing with the ramifications of these compromises will consume more and more energy as we’re attempting to pay off this debt. Over time, these “cracks in the foundation” will impede additional progress and the organization may even start to regress to the “pre-transformation state” due to the always present organizational inertia and tendency to revert back to previous state.

It comes down to this: Agile debt is real and at least as destructive as technical debt. So let’s not take the easy shortcuts, but focus on doing it right. Only that way will an Agile transformation “stick” and provide real and lasting benefits to an organization.

Agile is Everything – Everything is Agile

June 21, 2016 / rrosendahl / 0 Comments

As agilists, we are all fighting – to various extents – the perception that Agile is a set of processes, techniques, and (if we’re lucky enough that people understand this) mindsets to optimize software development teams. To some degree I can’t blame people for thinking that because that’s kinda how Agile got started. But nowadays Agile is taking a very holistic approach, a perspective that goes far beyond helping a team of developers function better. By the way, when I say “Agile”, I’m including Agile scaling frameworks as well as Lean and related product development approaches (so yes, I’m casting a pretty wide net, which is reflective of the close relationships between these different knowledge areas).

Here are additional angles Agile is looking at the world from and tries to impact:

Organizational agility: enabling the organization to act and react quickly to environmental and market conditions.
Portfolio management, i.e. understanding size and benefit of high-level initiatives and making optimal decisions for the business. Working on the right things (in the right order).
Systems thinking (vs. local optimizations), aimed at optimizing the whole process of value delivery, not just software development.
Removal of waste in processes and shortening cycle times of value delivery (not just creating shippable code).
Making decisions based on economical and empirical considerations.
The Lean Agile mindset which influences leadership style and organizational decision making.
Organizational culture, including, but not limited to trust, respect, empowerment, etc.
Organizational design and structure as well as performance management and recognition approaches.
Product development approaches, e.g. the Lean Startup.
Drive away from industrial era management beliefs and styles.
Accounting practices impacting if and how capitalization is practiced, budgeting and planning.
Appropriate metrics and KPIs.
Technical practices (CI, CD, DevOps) and quality practices (test automation etc.) and technical craftsmanship.
Architecture (think emergent architecture, loosely-coupled components, micro services, etc.)
Relentless (self-) improvement at all levels. Kaizen.
Team and interpersonal dynamics.
Team and organizational health.
Product innovation.

I probably forgot a few elements, but you get the gist. This is why agilists want to engage with and influence various levels in the organization, including senior management, and individuals in

Engineering, technology, architecture, quality (obviously)
IT infrastructure
Product management
Project management
Finance & accounting
Human resources

Hopefully over time the limited perception of Agile will be corrected by people and organizations understanding the holistic nature of Agile. With that approach, we can really unlock and enable the potential of an organization and its products.

Internal Agile Coaches – “Planting” vs. “Building”

June 11, 2016 / rrosendahl / 2 Comments

In recent years, more and more companies have realized the value of Agile coaching and the need to have full-time employees in the role of Agile coaches to help keep the Agile ship on course. The most effective candidate for this kind of job are people who’ve already played the role of Agile coach before and have gathered experience with several other companies, therefore companies often find themselves hiring coaches from consulting companies, people who want to “get off the road” and prefer to cut down on their travel and dedicate themselves to a single organization. As these former consultants get used to life inside an organization, it’s interesting that more often than not they have to adjust quite a bit and learn that what made them successful as a consultant will not make them successful inside an organization. To use an analogy, being successful as an internal Agile coach is more like “planting” whereas being an external coach and consultant is more analogous to “building”. Let me explain:

When an Agile consultant is brought into an organization, there is often a specific problem to solve that requires immediate attention and action, such as leading a transformation or increasing the maturity of a group of teams. The person comes in with with an objective and expectation of results, which may translate into some kind of mandate and organizational power and influence. It’s like building a house where quickly a foundation is laid upon which parts are assembled to produce a building, the desired outcome of an engagement. Ideally the building isn’t hacked together over a few days, but there is certainly the desire to complete the building upon a solid foundation over several weeks or months. Then the person moves on to the next building or leaves the organization with the goal accomplished.

As an internal Agile coach, the situation is quite different. Sometimes there is a specific short-term goal that needs to be accomplished quickly (e.g. launching a certain release train within the next 2 months), which requires functioning more like an external consultant, at least for some time. Apart from those circumstances, living as an internal coach inside an organization requires the newly hired coach to come in to build credibility and trust via relationships. Without these roots in the organization, the coach will not be successful. It’s about creating internal “pull” for coaching services and getting people to see the value in coaching, so that that they will want to consume this service. A new person entering a company in this role will find himself in more of a “planting” mode where he’ll put various seeds in the ground in several locations and continue to water. This process will take time and patience and only few plants will spring out of the ground quickly. In most cases it may take months for the majority of plants to take root and then emerge from the soil. There are no guarantees and shortcuts to accelerate the process. Despite best efforts, not all seeds will come to life. With the coach building solid relationships, trust and “pull”, ultimately large plants with deep roots will flourish over time. These plants are a natural extension of the environment and will hopefully be able to weather storms and persist long-term. This is different from erected buildings, which are typically more like foreign objects in nature, with more shallow foundations, which may make them more susceptible to natural forces.

Being a successful internal coach is challenging and hopefully this mental model is helpful in describing the differences between an external Agile consultant vs. an internal Agile coach. A slightly different way to think about this is via the comparison to “missionaries vs. mercenaries”. Mercenaries (external consultants) are being dropped in a tense situation with a short-term mission in mind which often requires swift and sometimes drastic action. Missionaries, on the other hand, will approach things with more compassion and pay more attention to the human side. Their efforts will certainly also require more time and they’ll still be there to deal with the results of their early work – good or bad (while external consultants would likely have moved on already at that time). They have “skin in the game” and focus on the long-term best interest of their organization.

Don’t get me wrong, based on the situation, either mode can be appropriate and I certainly don’t want to diminish the approach and work of external consultants. A really good coach, external or internal, will be able to assess the circumstances and have the experience and skills to apply the correct approach. All that said, becoming a long-term internal coach requires a different perspective that may not be as obvious coming from the consulting world.

Journey to the Center of SAFe

April 22, 2016 / rrosendahl / 0 Comments

I recently went through the SAFe SPC4 class, which was quite interesting in the light of my earlier post about “my problem with SAFe“. First and foremost, I wanted to understand SAFe better and kept an open mind throughout the experience.

Here are some first impressions:

The guys from Scaled Agile do understand Agile well and spent a good amount of time on the underlying principles.
SAFe is supportive of self-organizing and empowered teams, which is a good thing and maybe not what I would’ve expected.
The SAFe hierarchy does not imply that all items always flow top down. Work items can also be inserted horizontally and the framework includes a bottom up flow of information and collaboration. This is different from other hierarchical scaling models I’ve seen.
In SAFe 4, value streams were introduced and there’s admittedly not all that much experience with them. The transition from operational to development-centric value streams in the process of figuring the structure out is interesting but also confusing and not very clear. It’s still somewhat illusive to me how this is going to work and how to get from there to release trains.
Lots of material to cover in SPC4, lots of stuff…
I expected the framework to be more prescriptive, but as a matter of fact, the further up you go in the hierarchy, the more fuzzy it gets around roles, processes, etc. to the point where I wanted more information.
The PI planning ceremonies, which are to be run as big room planning events and are arguably the core of SAFe together with release trains, are logistically challenging and incredibly expensive. One could even argue that the PI (planning and innovation) sprint at the end of the PI is a sprint lost to make room for PI planning. I wonder if there are cheaper and easier ways to accomplish this.
The jury is still out whether pre- and post PI planning events are sufficient to really pull off a value stream planning.
Dependencies are what kills big Agile systems and while SAFe does a decent job of surfacing them, I’m not sensing they have magic sauce to deal with them either.
With any decent mass, i.e. number of teams, I’m struggling to see how sticky notes and paper can work during PI planning events although that is being advertised. I tend to think that without a decent ALM, this will be very hard to pull off and even more so with distributed teams.
Did I mention that the logistics of planning multiple release trains concurrently seems outrageous?
Release trains (ARTs) and PIs assume a lot of maturity, including the ability to more or less lock scope for an average of 10 weeks. That may be a challenge in quite a few environments. And starting teams that haven’t done Agile yet as release trains seems like a pretty big jump. And how do we deal with teams who can only plan 1-2 sprints ahead but are part of the ART due to dependencies with the other teams in the train?
SAFe 4.0 speaks to Kanban teams participating in release trains, but it’s not unite clear how exactly this will work and whether teams will be required to break some Kanban rules in the process. Scrum seems like a better fit.
I like the principle of “taking an economic view”, which I feel will be helpful at various levels.
SAFe does not mess with the team-level roles including the Product Owner. I like that the teams continue to have someone in the team that plays this critical role.
Not much time is spent talking about situations or circumstances where SAFe is not a good fit. For example: what about teams with volatile backlogs or teams that are able to function rather independently?
Scaled Agile itself is not so much a consulting company, but seems to focus more on and monetize education, training and licensing their materials.

Overall, this was a good class and really helped me understand the framework. Am I a believer? Not quite yet; as they say: “the proof is in the pudding”. That said, the number of companies claiming success with SAFe seems to indicate that the SAFe guys are onto something. I’m encouraged by Dean Leffingwell himself saying that he’s not married to SAFe itself and doesn’t get emotional about it. It’s simply something he found works pretty well, but if he finds something that proves to work better, he’ll do that instead. I’m glad I have SAFe in my toolbox now and am curious to try some stuff out!

Agile & Lean Product Development

Page 4 of 7

MVP, MLP, MMF and the whole Bunch