Agile & Lean Product Development

A Practical Approach to Agility and Product Management

Category: Uncategorized (Page 3 of 7)

Measurement and Agile – Oil and Water?

July 22, 2018 / / 0 Comments

The truth is that measuring things in software development is hard. As Edwards Deming clearly stated “The most important things cannot be measured.” We’ve all seen how metrics can be gamed and abused (velocity, anyone?) and many have heard of the “Law of Unintended Consequences” and experienced in practice how measurement led to unintended and counterproductive behaviors. So a lot of folks have jumped on the #NoEstimates bandwagon and we’re all better off not measuring anything at all, right?

I’m not sure it’s that easy. The reality is that we’re all living in the business world and we’re being asked to help answer certain, very valid questions, such as:

  •            What’s our customer satisfaction? How is it trending?
  •            How are our Agile teams doing? Are we getting better?
  •            How is our Agile / digital transformation progressing?
  •            Are we getting the value we were hoping for out of our transformation efforts, coaching, etc.?
  •            What ROI are we getting from the money we invest in our transformation?
  •            For consultants and coaches: Am I moving the needle and making an impact?
  •            Are we helping the organization deliver value faster?
  •            Where do we need to deploy our limited coaching resources?
  •            What bottlenecks in our value streams do we need to address?

While measurements are hard and there are certainly landmines to avoid, … Continue reading my full post here.

(Part 2, Part 3, Part 4)

Why “Yes” Doesn’t Scale

June 12, 2018 / / 0 Comments

Everyone loves a “can do” attitude. “Yes, we can!” has become – even when stripped of any political connotations – the rallying call of an entire generation, empowered, driven, and enthusiastic. For a young startup, this type of optimism is a prerequisite. Pessimists would probably never embark on a dangerous journey into uncharted waters, let alone survive the trials and tribulations that are an integral part of bringing a new product to market. But as startups grow, …

Continue reading on ProductCraft (where this full post has been published)

The Evolution of Product Management

April 18, 2018 / / 4 Comments

Product Management is a newer “function” and many companies don’t employ it from the beginning. Instead, it tends to emerge over time as companies start focusing on making their software products better. I’d like to describe a common pattern I’ve seen that shows how organizations often introduce Product and related functions in an Agile environment. Of course, not everyone will follow this pattern: the sequence may change or some may jump straight into later stages, but the main progressions is typically similar.

The starting point often looks like this:

“IT”/Technology is developing and operating software applications. Agile Product Owners (POs) exist, but they are typically part of the technology organization and often have less of a true Product background, but tend to have job titles like Business Analyst, etc.

As the organization doubles down on making the software products actual commercial products
and is ready to start emphasizing product as an actual craft and independent function of its own right, Product Management is introduced into the organization:

Continue reading

Project Runway

April 7, 2018 / / 0 Comments

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

March 18, 2018 / / 0 Comments

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

March 5, 2018 / / 0 Comments

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

November 18, 2017 / / 0 Comments

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

September 13, 2017 / / 0 Comments

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

« Older posts Newer posts »

© 2025 Agile & Lean Product Development

Theme by Anders Noren — Up ↑