Agile & Lean Product Development

A Practical Approach to Agility and Product Management

Page 3 of 6

Project Runway

Planning ahead in software development – just enough

Big Design Up Front (BDUF) is dead. There may not be too much agreement about any one thing in software development, but the industry has pretty much concluded that BDUF doesn’t work. 

As Agile practices and mindset took hold, up-front architecture was essentially looked down upon. And for good reason: in many cases, a system architecture can evolve and be adjusted over time as the system matures. We call this emergent design. (On the far side of the continuum of up-front planning, opposed to BDUF, lies “Just start coding”, which is still practiced quite a bit too, with varying degrees of success as it is more the extreme case, but may be sufficient in simple cases.) 

Another mantra circulating in Agile circles is to focus on and start with the easiest thing that can possibly work. This approach allows us to focus on solving the immediate problem at hand while ensuring we are not pursuing an overly complex solution. The theory is that – with the help of emergent design – the implementation can be adjusted down the line.

However, as organizations scaled their development teams and systems grew more complex, problems started to surface. It became problematic for several teams working on the same large solution to let design simply “emerge” in real-time, at the team level. After all, an application architecture is not fully malleable and might be resistant to change. And several teams working on the same application require coordination, agreement on architectural approach and at least some level of planning. A more intentional architecture was needed, without resorting back to the BDUF days. And therein lies the key, which is more art than science: finding the sweet spot between emergent design and intentional architecture (see Agile architecture). 

Continue reading

Methods of Communication – How “Slack” is Filling a New Gap

Slack, the instant messaging application, is seemingly ubiquitous among software developers and teams of various sizes and make ups nowadays. In recent years, its use has spread like wildfire and if there’s still a team that’s not using it and hanging on to things like Google Hangouts or Skype for Business, sooner or later someone on the team will suggest trying out Slack and the rest will be history. The fact that Slack is easy and free to set up makes the barrier of entry low and once a team starts, there’s usually no looking back. I’ve seen Slack take very deep roots in a corporate environment where the company tried to insist on using the “corporate standard” application, but to no avail: the developers basically ignored all such requests and insisted on using Slack.

But this post is not about how great Slack is (although it is arguably pretty cool and a great example for habit-forming application). It is about something else: After using the application for a few months with a globally distributed team, I noticed how it created a new mode of communication. Let me explain: Methods of human communication live on a scale of immediacy. On the far ends of this spectrum are the instantaneous, real-time methods such as voice and video (zero delay) and the method with the longest delay known as postal mail with days to weeks of delay (nothing is really any slower, assuming messages in bottles are out of scope).

The methods in the middle are a little more recent and interesting: There we have instant messages, SMS, and similar methods. While not exactly immediate or real-time, the expectation is usually that responses are received within minutes or maybe an hour at the longest. What about email? In my experience senders usually expect to hear back anywhere within 2 hrs to 1 business day.

So where does Slack fit in? It’s basically an instant messaging application, right? On the surface, yes. That’s where it all starts and that is certainly Slack’s core. One thing that makes Slack really sticky is the fact that you can transition to a real-time method. Involved in an intense back and forth with a colleague and the topic of conversation gets too complex or typing is getting too tedious? Well, you can now transition into Slack voice calls, video, or screen sharing (assuming you’re using the paid version).

Continue reading

Reducing Variability and the Airport Omelette

Like many times before, I was sitting in my favorite airport restaurant before my first flight and enjoyed my typical egg white omelette. Then I questioned myself: why don’t I eat breakfast at home instead and leave later for the airport? That didn’t feel right (apart from the fact that my home cooked omelettes don’t taste as good), until I realized there was a deeper reason for it: Eating at home meant leaving later, which would increase the likelihood of hitting traffic on the road and longer lines in the airport. Leaving later would also reduce the safety buffer I can rely on if something unforeseen happens. If worst came to worst, I could skip my airport breakfast and chow down a bar instead and still make my flight. If I ate at ours have that safety buffer.

Taking a step back, making a flight as well as completing work projects on time is about increasing predictability. One way to do that is to reduce schedule and other risks by eliminating variability early on in the process. So if a project consists of multiple sequential steps, it makes sense to eliminate variables as early as possible and take on those tasks that have the highest possible variability first (assuming the tasks can be resequenced accordingly).

This is very much in line with Agile’s recommendation to take on those stories and features with the highest level of technical risk first. It’s all about reducing risk and increasing predictability.

Wait, you might say, doesn’t SAFe propose to preserve options and defer decisions till the last responsible moment? Yes. If these options bear the same amount of risk and variability, doing so may not necessarily increase project duration and risk, but it certainly doesn’t remove variability early on. The goal here is to stay responsive to changes in market and business demands and not place technical bets until necessary.

In practice, one will need to find the right sweet spot between reducing variability and preserving options as those two approaching are some what opposites sides of the same continuum. SAFe practitioners are, at the end of the day, also incentivized to be predictable and meet PI commitments, if possible.

Now that I understand why my usual airport omelette actually helps me make my early flight, I will certainly keep my eyes open for other opportunities in my life to reduce variability and increase predictability where it matters.

The Importance of Mental Models in Application Design

By René Rosendahl

I have written before about ease of use and the key characteristics of applications that are perceived as user-friendly. In this post, I’d like to dive deeper into what I call the “mental model” that underlies applications. I would define the mental model as the intuitive perception a user has or develops about how an application is organized and how it performs its tasks.

The mental model has two key components:

  • The information architecture: How do the various elements used within an application relate to each other?
  • The process flow: Which steps does the user of an application have to perform to accomplish a task and what states do the elements of the application move in between? What business rules apply?

The reason I wrote earlier that the user may already have a mental model in mind when starting to use a new application is that none of us is a blank slate. Based on prior experiences, we already have several very specific mental models we’re using or trying to apply when confronted with an unknown application. Let’s look at a few examples of existing mental models we already have:

Continue reading

Pressure Filters in Agile Organizations

Nowadays, everyone feels pressure in an organization. Traditionally pressure has been viewed as starting at the top of the org chart and permeating and cascading down in the organization. For this discussion, let’s assume the pressure originates outside an organization as market or customer pressures. Those are often to deliver features and services and to do so faster and more cheaply. Patience is not a key virtue of today’s economy.

In an organization that subscribes to Agile values and processes, the pressure takes the following path:

 

  • The market and customers require services and features faster, cheaper and at higher quality.
  • Leadership (management, sales, customer success, marketing, finance, etc.) respond by putting pressure on the Product organization, which is – at the end of the day – represented by Product Managers and Product Owners.
  • Product Owners ask for the Agile team(s) to delivery stories and features at high speed, but with good quality.
  • The Scrum Master acts as protector of the team and helps negotiate a feasible commitment (related to scope and time).
  • The Agile team attempts to deliver against their forecast/commitment.

 

Continue reading

MVP, MLP, MMF and the whole Bunch

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

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:

  1. 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..
  2. 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.
  3. 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:

  1. Growth items get identified through Agile ceremonies such as sprint retrospectives or strategic retrospectives as suggested by AgilityHealth.
  2. Growth items get collected in a growth backlog and prioritized.
  3. 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.
  4. 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.
  5. 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.
  6. Out of all items on the growth backlog, the most pressing items will hopefully see resolution by teams and leadership.
  7. The immediate impact of resolved growth items is improved team health, which has various components including morale/happiness, effectiveness, level of collaboration, and skills.
  8. 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?

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-chartWhen 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

casOn 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.

« Older posts Newer posts »